* 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.