All of lore.kernel.org
 help / color / mirror / Atom feed
* Why is PEB not erased before writing???
@ 2007-02-20  6:37 Brijesh Singh
  2007-02-20  9:34 ` Thomas Gleixner
  0 siblings, 1 reply; 9+ messages in thread
From: Brijesh Singh @ 2007-02-20  6:37 UTC (permalink / raw)
  To: linux-mtd

I tried to overwrite same block.
Ubi should call erase before overwriting the data block.But it didn't.
UBI simply wrote the block again.That will write garbage for a flash.
So who will call erase??Is it the application's responsibility to call
erase before writing at same  location???

I am stuck here because my concept was,
ubi will check if we are re-writing the same PEB.
If yes,UBI will erase the block and then write the same block.

Regards,
BRIJESH

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Why is PEB not erased before writing???
  2007-02-20  6:37 Why is PEB not erased before writing??? Brijesh Singh
@ 2007-02-20  9:34 ` Thomas Gleixner
  2007-02-20  9:49   ` brijesh.singh
  0 siblings, 1 reply; 9+ messages in thread
From: Thomas Gleixner @ 2007-02-20  9:34 UTC (permalink / raw)
  To: Brijesh Singh; +Cc: linux-mtd

On Tue, 2007-02-20 at 12:07 +0530, Brijesh Singh wrote:
> I tried to overwrite same block.
> Ubi should call erase before overwriting the data block.But it didn't.
> UBI simply wrote the block again.That will write garbage for a flash.
> So who will call erase??Is it the application's responsibility to call
> erase before writing at same  location???
> 
> I am stuck here because my concept was,
> ubi will check if we are re-writing the same PEB.
> If yes,UBI will erase the block and then write the same block.

Applications and UBI kernel users have no access to physical erase
blocks. They look at logical erase blocks. UBI manages the translation
of logical to physical blocks. If you write to the same logical erase
block again UBI will just write to a different physical erase block and
erase the previous PEB later on. The internal management guarantees that
the application looks only at the newest written block and not at the
older one.

	tglx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Why is PEB not erased before writing???
  2007-02-20  9:34 ` Thomas Gleixner
@ 2007-02-20  9:49   ` brijesh.singh
  2007-02-20 10:44     ` Thomas Gleixner
  0 siblings, 1 reply; 9+ messages in thread
From: brijesh.singh @ 2007-02-20  9:49 UTC (permalink / raw)
  To: tglx; +Cc: Brijesh Singh, linux-mtd


> On Tue, 2007-02-20 at 12:07 +0530, Brijesh Singh wrote:
>> I tried to overwrite same block.
>> Ubi should call erase before overwriting the data block.But it didn't.
>> UBI simply wrote the block again.That will write garbage for a flash.
>> So who will call erase??Is it the application's responsibility to call
>> erase before writing at same  location???
>>
>> I am stuck here because my concept was,
>> ubi will check if we are re-writing the same PEB.
>> If yes,UBI will erase the block and then write the same block.
>
> Applications and UBI kernel users have no access to physical erase
> blocks. They look at logical erase blocks. UBI manages the translation
> of logical to physical blocks. If you write to the same logical erase
> block again UBI will just write to a different physical erase block and
> erase the previous PEB later on. The internal management guarantees that
> the application looks only at the newest written block and not at the
> older one.

Yes this is what I thought it should do.If LEB is mapped to a dirty PEB
remap it and wl daemon will erase it.But it doesn't.
But here is the scenario
Steps
     *I made a 2MB ubi volume
     *Total mtd device size is 3MB
     *I wrote a 2MB file to UBI using "dd if=file of=/dev/ubi_vol"
     *Now device is full
     *Again I did the same thing.
     *Now theoretically erase should have been called,by wl or eba module
     *But it directly over-writes the device.
I am using mtdram to test if erase is called.Nop,it is not.
Cdev write interface calls eba_write which doesn't check if block is
already written.And it over-writes it with no call to erase.
Now what to do?Erase is not even called!

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Why is PEB not erased before writing???
  2007-02-20  9:49   ` brijesh.singh
@ 2007-02-20 10:44     ` Thomas Gleixner
  2007-02-20 11:08       ` Brijesh Singh
  2007-02-20 11:11       ` Brijesh Singh
  0 siblings, 2 replies; 9+ messages in thread
From: Thomas Gleixner @ 2007-02-20 10:44 UTC (permalink / raw)
  To: brijesh.singh; +Cc: Brijesh Singh, linux-mtd

On Tue, 2007-02-20 at 15:19 +0530, brijesh.singh@calsoftinc.com wrote:
> > Applications and UBI kernel users have no access to physical erase
> > blocks. They look at logical erase blocks. UBI manages the translation
> > of logical to physical blocks. If you write to the same logical erase
> > block again UBI will just write to a different physical erase block and
> > erase the previous PEB later on. The internal management guarantees that
> > the application looks only at the newest written block and not at the
> > older one.
> 
> Yes this is what I thought it should do.If LEB is mapped to a dirty PEB
> remap it and wl daemon will erase it.But it doesn't.
> But here is the scenario
> Steps
>      *I made a 2MB ubi volume
>      *Total mtd device size is 3MB
>      *I wrote a 2MB file to UBI using "dd if=file of=/dev/ubi_vol"
>      *Now device is full
>      *Again I did the same thing.
>      *Now theoretically erase should have been called,by wl or eba module
>      *But it directly over-writes the device.
> I am using mtdram to test if erase is called.Nop,it is not.
> Cdev write interface calls eba_write which doesn't check if block is
> already written.And it over-writes it with no call to erase.
> Now what to do?Erase is not even called!

Did you enable CONFIG_MTD_USERSPACE_IO ? If yes, then the behaviour is
clear. This is a _DEBUG_ option and bypasses the normal update
procedure.

	tglx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Why is PEB not erased before writing???
  2007-02-20 10:44     ` Thomas Gleixner
@ 2007-02-20 11:08       ` Brijesh Singh
  2007-02-20 11:11       ` Brijesh Singh
  1 sibling, 0 replies; 9+ messages in thread
From: Brijesh Singh @ 2007-02-20 11:08 UTC (permalink / raw)
  To: tglx; +Cc: linux-mtd, brijesh.singh

On 2/20/07, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Tue, 2007-02-20 at 15:19 +0530, brijesh.singh@calsoftinc.com wrote:
> > > Applications and UBI kernel users have no access to physical erase
> > > blocks. They look at logical erase blocks. UBI manages the translation
> > > of logical to physical blocks. If you write to the same logical erase
> > > block again UBI will just write to a different physical erase block and
> > > erase the previous PEB later on. The internal management guarantees that
> > > the application looks only at the newest written block and not at the
> > > older one.
> >
> > Yes this is what I thought it should do.If LEB is mapped to a dirty PEB
> > remap it and wl daemon will erase it.But it doesn't.
> > But here is the scenario
> > Steps
> >      *I made a 2MB ubi volume
> >      *Total mtd device size is 3MB
> >      *I wrote a 2MB file to UBI using "dd if=file of=/dev/ubi_vol"
> >      *Now device is full
> >      *Again I did the same thing.
> >      *Now theoretically erase should have been called,by wl or eba module
> >      *But it directly over-writes the device.
> > I am using mtdram to test if erase is called.Nop,it is not.
> > Cdev write interface calls eba_write which doesn't check if block is
> > already written.And it over-writes it with no call to erase.
> > Now what to do?Erase is not even called!
>
> Did you enable CONFIG_MTD_USERSPACE_IO ? If yes, then the behaviour is
> clear. This is a _DEBUG_ option and bypasses the normal update
> procedure.
>
>         tglx
>
>
>

Yes I did enable this CONFIG_MTD_UBI_USERSPACE_IO  option.We can't
write the device if this flag is not enabled.UBI treats the device as
readonly.
This  is the usual way to write UBI device,I guess.

UBI doesn't maintain which write sub-block is dirty.Most of the
hardwares don't give error if user is "not writing free sub-block".
There is a paranoid check in ubi_io_write_data to check all 0xFF but
not a mainline check

The call hirerchy of write is,
cdev- write
eba-write
     if mapped
                io_write_data               <------ here if I am
over-writing the sub-block(NOT 0xFF),
                                                            UBI should
                                                            copy
block,get a free PEB,write this block without
     else                                                  old
sub-block and write new sub-block
               map LEB-PEB
               io_write_data
io-write
   call mtd-write

So whose job is to check block is not empty,so erase it then write it.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Why is PEB not erased before writing???
  2007-02-20 10:44     ` Thomas Gleixner
  2007-02-20 11:08       ` Brijesh Singh
@ 2007-02-20 11:11       ` Brijesh Singh
  2007-02-20 11:17         ` Thomas Gleixner
  1 sibling, 1 reply; 9+ messages in thread
From: Brijesh Singh @ 2007-02-20 11:11 UTC (permalink / raw)
  To: tglx; +Cc: linux-mtd, brijesh.singh

On 2/20/07, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Tue, 2007-02-20 at 15:19 +0530, brijesh.singh@calsoftinc.com wrote:
> > > Applications and UBI kernel users have no access to physical erase
> > > blocks. They look at logical erase blocks. UBI manages the translation
> > > of logical to physical blocks. If you write to the same logical erase
> > > block again UBI will just write to a different physical erase block and
> > > erase the previous PEB later on. The internal management guarantees that
> > > the application looks only at the newest written block and not at the
> > > older one.
> >
> > Yes this is what I thought it should do.If LEB is mapped to a dirty PEB
> > remap it and wl daemon will erase it.But it doesn't.
> > But here is the scenario
> > Steps
> >      *I made a 2MB ubi volume
> >      *Total mtd device size is 3MB
> >      *I wrote a 2MB file to UBI using "dd if=file of=/dev/ubi_vol"
> >      *Now device is full
> >      *Again I did the same thing.
> >      *Now theoretically erase should have been called,by wl or eba module
> >      *But it directly over-writes the device.
> > I am using mtdram to test if erase is called.Nop,it is not.
> > Cdev write interface calls eba_write which doesn't check if block is
> > already written.And it over-writes it with no call to erase.
> > Now what to do?Erase is not even called!
>
> Did you enable CONFIG_MTD_USERSPACE_IO ? If yes, then the behaviour is
> clear. This is a _DEBUG_ option and bypasses the normal update
> procedure.
>
>         tglx
>
>
>

Yes I did enable this CONFIG_MTD_UBI_USERSPACE_IO  option.We can't
write the device if this flag is not enabled.UBI treats the device as
readonly.
This  is the usual way to write UBI device,I guess.

UBI doesn't maintain which write sub-block is dirty.Most of the
hardwares don't give error if user is "not writing free sub-block".
There is a paranoid check in ubi_io_write_data to check all 0xFF but
not a mainline check

The call hirerchy of write is,
cdev- write
eba-write
    if mapped
               io_write_data
 <------ here if I am over-writing the sub-block(NOT 0xFF),
                                               UBI should copy
block,get a free PEB,write this block without  old sub-block and write
new sub-block
---->
else
              map LEB-PEB
              io_write_data
io-write
  call mtd-write

So whose job is to check block is not empty,so erase it then write it.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Why is PEB not erased before writing???
  2007-02-20 11:11       ` Brijesh Singh
@ 2007-02-20 11:17         ` Thomas Gleixner
  2007-02-20 21:48           ` Gavin Lambert
  0 siblings, 1 reply; 9+ messages in thread
From: Thomas Gleixner @ 2007-02-20 11:17 UTC (permalink / raw)
  To: Brijesh Singh; +Cc: linux-mtd, brijesh.singh

On Tue, 2007-02-20 at 16:41 +0530, Brijesh Singh wrote:
> > Did you enable CONFIG_MTD_USERSPACE_IO ? If yes, then the behaviour is
> > clear. This is a _DEBUG_ option and bypasses the normal update
> > procedure.
>
> Yes I did enable this CONFIG_MTD_UBI_USERSPACE_IO  option.We can't
> write the device if this flag is not enabled.UBI treats the device as
> readonly.
> This  is the usual way to write UBI device,I guess.

No. It is not. It is a _DEBUG_ option. UBI has an update mechanism. See
documentation.

	tglx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: Why is PEB not erased before writing???
  2007-02-20 11:17         ` Thomas Gleixner
@ 2007-02-20 21:48           ` Gavin Lambert
  2007-02-20 22:29             ` Thomas Gleixner
  0 siblings, 1 reply; 9+ messages in thread
From: Gavin Lambert @ 2007-02-20 21:48 UTC (permalink / raw)
  To: tglx; +Cc: linux-mtd

Quoth Thomas Gleixner [tglx@linutronix.de]:
> On Tue, 2007-02-20 at 16:41 +0530, Brijesh Singh wrote:
>> Yes I did enable this CONFIG_MTD_UBI_USERSPACE_IO  option.We can't
>> write the device if this flag is not enabled.UBI treats the device as
>> readonly. This  is the usual way to write UBI device,I guess.
> 
> No. It is not. It is a _DEBUG_ option. UBI has an update mechanism.
> See documentation. 

Perhaps it needs to be named better then :)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: Why is PEB not erased before writing???
  2007-02-20 21:48           ` Gavin Lambert
@ 2007-02-20 22:29             ` Thomas Gleixner
  0 siblings, 0 replies; 9+ messages in thread
From: Thomas Gleixner @ 2007-02-20 22:29 UTC (permalink / raw)
  To: Gavin Lambert; +Cc: linux-mtd

On Wed, 2007-02-21 at 10:48 +1300, Gavin Lambert wrote:
> Quoth Thomas Gleixner [tglx@linutronix.de]:
> > On Tue, 2007-02-20 at 16:41 +0530, Brijesh Singh wrote:
> >> Yes I did enable this CONFIG_MTD_UBI_USERSPACE_IO  option.We can't
> >> write the device if this flag is not enabled.UBI treats the device as
> >> readonly. This  is the usual way to write UBI device,I guess.
> > 
> > No. It is not. It is a _DEBUG_ option. UBI has an update mechanism.
> > See documentation. 
> 
> Perhaps it needs to be named better then :)

1. It is only available, when you enable CONFIG_MTD_UBI_DEBUG

2. From the help text of CONFIG_MTD_UBI_USERSPACE_IO:
"By default, users cannot directly write and erase individual
eraseblocks of dynamic volumes (the update operation must be used
instead). This option enables this capability - this is often useful for
debugging."

Better names are not really preventing PEBKAC scenarios.

	tglx

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2007-02-20 22:24 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-20  6:37 Why is PEB not erased before writing??? Brijesh Singh
2007-02-20  9:34 ` Thomas Gleixner
2007-02-20  9:49   ` brijesh.singh
2007-02-20 10:44     ` Thomas Gleixner
2007-02-20 11:08       ` Brijesh Singh
2007-02-20 11:11       ` Brijesh Singh
2007-02-20 11:17         ` Thomas Gleixner
2007-02-20 21:48           ` Gavin Lambert
2007-02-20 22:29             ` Thomas Gleixner

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.