Re: ubiblock RW

Re: ubiblock RW

[Ezequiel Garcia]

+MTD

On 23 March 2016 at 14:40, Benson Young <benson6877@gmail.com> wrote:
> Hello Ezequiel,
>
> I came upon the discussion about block device emulation over UBI.
> http://linux-mtd.infradead.narkive.com/YF0XOFxY/block-device-emulation-on-top-of-ubi-volumes-with-read-write-support
>
> I understand the most recent implementation is read-only emulation for
> mounting squashfs based file system.
> However, I would really like to see the write option be brought back. If
> not, can you please help me about enabling the write option in my build?
> I have used the patch listed in the following link
> https://lwn.net/Articles/525957/
> but i couldn't find any accompanying util that allows me to create the ubi
> block volume.
>

You should be able to use mtd-utils' ubiblock tool (maybe you'll need to do
some modifications).

http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubiblock

> Reason for this request is that I am looking into root file system
> encryption over un-managed NAND flash. Now the mainline method of disk
> encryption in Linux revolves around
> dm-crypt module which requires a block device. i am under the impression
> that using mtdblock works to an extent until the partition you try to
> map/encrypt has bad blocks in it.
> I have seen discussion about using UBIFS, and I have seen a paper discussing
> it, where the author embeds the encryption engine within UBI layer, so each
> write and read is encrypted. However, its a path I would take when I have no
> choice. Right now dm-crypt is my first choice basically because of the
> availability of support/discussion/information.
>
> I also saw you mentioned that you don't have NAND flash for testing, this is
> something that I can help with. I have an abundance of NAND flash devices.

I have some devices with SLC NANDs now, but thanks for the offer.

> For simplicity sake, I work with SLC because of better endurance compared to
> MLC. I am also curious about flash endurance with EXT4 over UBI. Destructive
> erase/write will definitely on my to-do list.
>

So, like I said here:

http://linux-mtd.infradead.narkive.com/YF0XOFxY/block-device-emulation-on-top-of-ubi-volumes-with-read-write-support

We can definitely implement write support if we have a good use case for it.
Encryption might be one.

Richard, what do you think?
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

Re: ubiblock RW

[Richard Weinberger]

Hi!

Am 24.03.2016 um 15:23 schrieb Ezequiel Garcia:
> +MTD
> 
> On 23 March 2016 at 14:40, Benson Young <benson6877@gmail.com> wrote:
>> Hello Ezequiel,
>>
>> I came upon the discussion about block device emulation over UBI.
>> http://linux-mtd.infradead.narkive.com/YF0XOFxY/block-device-emulation-on-top-of-ubi-volumes-with-read-write-support
>>
>> I understand the most recent implementation is read-only emulation for
>> mounting squashfs based file system.
>> However, I would really like to see the write option be brought back. If
>> not, can you please help me about enabling the write option in my build?
>> I have used the patch listed in the following link
>> https://lwn.net/Articles/525957/
>> but i couldn't find any accompanying util that allows me to create the ubi
>> block volume.
>>
> 
> You should be able to use mtd-utils' ubiblock tool (maybe you'll need to do
> some modifications).
> 
> http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubiblock
> 
>> Reason for this request is that I am looking into root file system
>> encryption over un-managed NAND flash. Now the mainline method of disk
>> encryption in Linux revolves around
>> dm-crypt module which requires a block device. i am under the impression
>> that using mtdblock works to an extent until the partition you try to
>> map/encrypt has bad blocks in it.
>> I have seen discussion about using UBIFS, and I have seen a paper discussing
>> it, where the author embeds the encryption engine within UBI layer, so each
>> write and read is encrypted. However, its a path I would take when I have no
>> choice. Right now dm-crypt is my first choice basically because of the
>> availability of support/discussion/information.
>>
>> I also saw you mentioned that you don't have NAND flash for testing, this is
>> something that I can help with. I have an abundance of NAND flash devices.
> 
> I have some devices with SLC NANDs now, but thanks for the offer.
> 
>> For simplicity sake, I work with SLC because of better endurance compared to
>> MLC. I am also curious about flash endurance with EXT4 over UBI. Destructive
>> erase/write will definitely on my to-do list.
>>
> 
> So, like I said here:
> 
> http://linux-mtd.infradead.narkive.com/YF0XOFxY/block-device-emulation-on-top-of-ubi-volumes-with-read-write-support
> 
> We can definitely implement write support if we have a good use case for it.
> Encryption might be one.
> 
> Richard, what do you think?

I'm definitely not fond of adding write support to ubiblock without turning it into a proper FTL.
Otherwise it will be abused and will cause serious damage.

Regarding encryption, encryption for UBIFS is in the pipes, Dave and I did already some preliminary
work. It will materialize within this year, depending on how much we get distracted by other projects.
So far it is a spare time project. The plan is adding file level encryption like ext4 and f2fs have.

Thanks,
//richard

Re: ubiblock RW

[Ezequiel Garcia]

On 24 March 2016 at 17:38, Richard Weinberger <richard@nod.at> wrote:
> Hi!
>
> Am 24.03.2016 um 15:23 schrieb Ezequiel Garcia:
>> +MTD
>>
>> On 23 March 2016 at 14:40, Benson Young <benson6877@gmail.com> wrote:
>>> Hello Ezequiel,
>>>
>>> I came upon the discussion about block device emulation over UBI.
>>> http://linux-mtd.infradead.narkive.com/YF0XOFxY/block-device-emulation-on-top-of-ubi-volumes-with-read-write-support
>>>
>>> I understand the most recent implementation is read-only emulation for
>>> mounting squashfs based file system.
>>> However, I would really like to see the write option be brought back. If
>>> not, can you please help me about enabling the write option in my build?
>>> I have used the patch listed in the following link
>>> https://lwn.net/Articles/525957/
>>> but i couldn't find any accompanying util that allows me to create the ubi
>>> block volume.
>>>
>>
>> You should be able to use mtd-utils' ubiblock tool (maybe you'll need to do
>> some modifications).
>>
>> http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubiblock
>>
>>> Reason for this request is that I am looking into root file system
>>> encryption over un-managed NAND flash. Now the mainline method of disk
>>> encryption in Linux revolves around
>>> dm-crypt module which requires a block device. i am under the impression
>>> that using mtdblock works to an extent until the partition you try to
>>> map/encrypt has bad blocks in it.
>>> I have seen discussion about using UBIFS, and I have seen a paper discussing
>>> it, where the author embeds the encryption engine within UBI layer, so each
>>> write and read is encrypted. However, its a path I would take when I have no
>>> choice. Right now dm-crypt is my first choice basically because of the
>>> availability of support/discussion/information.
>>>
>>> I also saw you mentioned that you don't have NAND flash for testing, this is
>>> something that I can help with. I have an abundance of NAND flash devices.
>>
>> I have some devices with SLC NANDs now, but thanks for the offer.
>>
>>> For simplicity sake, I work with SLC because of better endurance compared to
>>> MLC. I am also curious about flash endurance with EXT4 over UBI. Destructive
>>> erase/write will definitely on my to-do list.
>>>
>>
>> So, like I said here:
>>
>> http://linux-mtd.infradead.narkive.com/YF0XOFxY/block-device-emulation-on-top-of-ubi-volumes-with-read-write-support
>>
>> We can definitely implement write support if we have a good use case for it.
>> Encryption might be one.
>>
>> Richard, what do you think?
>
> I'm definitely not fond of adding write support to ubiblock without turning it into a proper FTL.
> Otherwise it will be abused and will cause serious damage.
>

I'm not sure this statement makes much sense without actual numbers.

Of course, eraseblocks will be erased much more often with a regular
block-oriented
filesystem. But a user could agressively control write access and prevent this.

Would it be that bad to add write support and add some big warning to
prevent users about potential damage?

-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

Re: ubiblock RW

[Willy Tarreau]

On Thu, Mar 24, 2016 at 06:26:44PM -0300, Ezequiel Garcia wrote:
> On 24 March 2016 at 17:38, Richard Weinberger <richard@nod.at> wrote:
> > Hi!
> >
> > Am 24.03.2016 um 15:23 schrieb Ezequiel Garcia:
> >> +MTD
> >>
> >> On 23 March 2016 at 14:40, Benson Young <benson6877@gmail.com> wrote:
> >>> Hello Ezequiel,
> >>>
> >>> I came upon the discussion about block device emulation over UBI.
> >>> http://linux-mtd.infradead.narkive.com/YF0XOFxY/block-device-emulation-on-top-of-ubi-volumes-with-read-write-support
> >>>
> >>> I understand the most recent implementation is read-only emulation for
> >>> mounting squashfs based file system.
> >>> However, I would really like to see the write option be brought back. If
> >>> not, can you please help me about enabling the write option in my build?
> >>> I have used the patch listed in the following link
> >>> https://lwn.net/Articles/525957/
> >>> but i couldn't find any accompanying util that allows me to create the ubi
> >>> block volume.
> >>>
> >>
> >> You should be able to use mtd-utils' ubiblock tool (maybe you'll need to do
> >> some modifications).
> >>
> >> http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubiblock
> >>
> >>> Reason for this request is that I am looking into root file system
> >>> encryption over un-managed NAND flash. Now the mainline method of disk
> >>> encryption in Linux revolves around
> >>> dm-crypt module which requires a block device. i am under the impression
> >>> that using mtdblock works to an extent until the partition you try to
> >>> map/encrypt has bad blocks in it.
> >>> I have seen discussion about using UBIFS, and I have seen a paper discussing
> >>> it, where the author embeds the encryption engine within UBI layer, so each
> >>> write and read is encrypted. However, its a path I would take when I have no
> >>> choice. Right now dm-crypt is my first choice basically because of the
> >>> availability of support/discussion/information.
> >>>
> >>> I also saw you mentioned that you don't have NAND flash for testing, this is
> >>> something that I can help with. I have an abundance of NAND flash devices.
> >>
> >> I have some devices with SLC NANDs now, but thanks for the offer.
> >>
> >>> For simplicity sake, I work with SLC because of better endurance compared to
> >>> MLC. I am also curious about flash endurance with EXT4 over UBI. Destructive
> >>> erase/write will definitely on my to-do list.
> >>>
> >>
> >> So, like I said here:
> >>
> >> http://linux-mtd.infradead.narkive.com/YF0XOFxY/block-device-emulation-on-top-of-ubi-volumes-with-read-write-support
> >>
> >> We can definitely implement write support if we have a good use case for it.
> >> Encryption might be one.
> >>
> >> Richard, what do you think?
> >
> > I'm definitely not fond of adding write support to ubiblock without turning it into a proper FTL.
> > Otherwise it will be abused and will cause serious damage.
> >
> 
> I'm not sure this statement makes much sense without actual numbers.
> 
> Of course, eraseblocks will be erased much more often with a regular
> block-oriented
> filesystem. But a user could agressively control write access and prevent this.
> 
> Would it be that bad to add write support and add some big warning to
> prevent users about potential damage?

+1, we're on linux, we're supposed to let the user shoot himself in the foot
if he really *wants* to do so. But we must warn him so that it's not an
accident. There are many other ways to destroy a flash anyway, I guess that
running flash_erase in loops will achieve the same result, so we're not
protecting much against stupid actions by removing useful features and we're
only inciting users to work around them by employing possibly even uglier
solutions (FS directly on mtdblock maybe ?).

Willy

Re: ubiblock RW

[Richard Weinberger]

Am 24.03.2016 um 22:39 schrieb Willy Tarreau:
> On Thu, Mar 24, 2016 at 06:26:44PM -0300, Ezequiel Garcia wrote:
>> On 24 March 2016 at 17:38, Richard Weinberger <richard@nod.at> wrote:
>>> Hi!
>>>
>>> Am 24.03.2016 um 15:23 schrieb Ezequiel Garcia:
>>>> +MTD
>>>>
>>>> On 23 March 2016 at 14:40, Benson Young <benson6877@gmail.com> wrote:
>>>>> Hello Ezequiel,
>>>>>
>>>>> I came upon the discussion about block device emulation over UBI.
>>>>> http://linux-mtd.infradead.narkive.com/YF0XOFxY/block-device-emulation-on-top-of-ubi-volumes-with-read-write-support
>>>>>
>>>>> I understand the most recent implementation is read-only emulation for
>>>>> mounting squashfs based file system.
>>>>> However, I would really like to see the write option be brought back. If
>>>>> not, can you please help me about enabling the write option in my build?
>>>>> I have used the patch listed in the following link
>>>>> https://lwn.net/Articles/525957/
>>>>> but i couldn't find any accompanying util that allows me to create the ubi
>>>>> block volume.
>>>>>
>>>>
>>>> You should be able to use mtd-utils' ubiblock tool (maybe you'll need to do
>>>> some modifications).
>>>>
>>>> http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubiblock
>>>>
>>>>> Reason for this request is that I am looking into root file system
>>>>> encryption over un-managed NAND flash. Now the mainline method of disk
>>>>> encryption in Linux revolves around
>>>>> dm-crypt module which requires a block device. i am under the impression
>>>>> that using mtdblock works to an extent until the partition you try to
>>>>> map/encrypt has bad blocks in it.
>>>>> I have seen discussion about using UBIFS, and I have seen a paper discussing
>>>>> it, where the author embeds the encryption engine within UBI layer, so each
>>>>> write and read is encrypted. However, its a path I would take when I have no
>>>>> choice. Right now dm-crypt is my first choice basically because of the
>>>>> availability of support/discussion/information.
>>>>>
>>>>> I also saw you mentioned that you don't have NAND flash for testing, this is
>>>>> something that I can help with. I have an abundance of NAND flash devices.
>>>>
>>>> I have some devices with SLC NANDs now, but thanks for the offer.
>>>>
>>>>> For simplicity sake, I work with SLC because of better endurance compared to
>>>>> MLC. I am also curious about flash endurance with EXT4 over UBI. Destructive
>>>>> erase/write will definitely on my to-do list.
>>>>>
>>>>
>>>> So, like I said here:
>>>>
>>>> http://linux-mtd.infradead.narkive.com/YF0XOFxY/block-device-emulation-on-top-of-ubi-volumes-with-read-write-support
>>>>
>>>> We can definitely implement write support if we have a good use case for it.
>>>> Encryption might be one.
>>>>
>>>> Richard, what do you think?
>>>
>>> I'm definitely not fond of adding write support to ubiblock without turning it into a proper FTL.
>>> Otherwise it will be abused and will cause serious damage.
>>>
>>
>> I'm not sure this statement makes much sense without actual numbers.
>>
>> Of course, eraseblocks will be erased much more often with a regular
>> block-oriented
>> filesystem. But a user could agressively control write access and prevent this.
>>
>> Would it be that bad to add write support and add some big warning to
>> prevent users about potential damage?
> 
> +1, we're on linux, we're supposed to let the user shoot himself in the foot
> if he really *wants* to do so. But we must warn him so that it's not an
> accident. There are many other ways to destroy a flash anyway, I guess that
> running flash_erase in loops will achieve the same result, so we're not
> protecting much against stupid actions by removing useful features and we're
> only inciting users to work around them by employing possibly even uglier
> solutions (FS directly on mtdblock maybe ?).

Okay, that's a good point.
A parameter for the ubiblock tool a la "--enable-rw-i-know-what-im-doing" should be fine.

Thanks,
//richard

Re: ubiblock RW

[Artem Bityutskiy]

On Thu, 2016-03-24 at 18:26 -0300, Ezequiel Garcia wrote:
> > > Richard, what do you think?
> > I'm definitely not fond of adding write support to ubiblock without
> > turning it into a proper FTL.
> > Otherwise it will be abused and will cause serious damage.
> > 
> I'm not sure this statement makes much sense without actual numbers.

Ezequel,

could you re-summarize how the write support would be implemented? Read
entire LEB, modify data block (512 bytes), atomically write the LEB?
This would not perform well, but would probably work.

Or you want to avoid atomic LEB change and just erase the LEB and write
the entire LEB with the updated contents? This would probably be a bit
faster, but not power-cut safe.

Re: ubiblock RW

[Ezequiel Garcia]

On 25 Mar 01:51 PM, Artem Bityutskiy wrote:
> On Thu, 2016-03-24 at 18:26 -0300, Ezequiel Garcia wrote:
> > > > Richard, what do you think?
> > > I'm definitely not fond of adding write support to ubiblock without
> > > turning it into a proper FTL.
> > > Otherwise it will be abused and will cause serious damage.
> > > 
> > I'm not sure this statement makes much sense without actual numbers.
> 
> Ezequel,
> 
> could you re-summarize how the write support would be implemented? Read
> entire LEB, modify data block (512 bytes), atomically write the LEB?
> This would not perform well, but would probably work.
> 

Yes, I was thinking in using atomic LEB change. The old write-support
was implemented with a 1-LEB cache vmalloced at open, and freed at release.

The flash device is written when the write cache is flushed on:
  * block device release (detach)
  * a different than cached leb is accessed (either through read or write)
  * io-barrier is received through a REQ_FLUSH request

It was expected that the block I/O scheduler would help mitigate
the effects of a regular block oriented filesystem on flash sector
erasecount.

However, most likely UBIFS will do a far better job at preserving
flash wear than any block oriented filesystem.

> Or you want to avoid atomic LEB change and just erase the LEB and write
> the entire LEB with the updated contents? This would probably be a bit
> faster, but not power-cut safe.
> 

Not sure dropping power-cut safeness a realistic option. I'd say
most -if not all- users will want to be power-cut safe at all costs.

Let me quote a mail here from Willy [1]:

""
[..] I've been using ext2 on x86-based hardware and compact flash for
something like 10 years with a great success (easy to mount, easy to
fix, easy to save, easy to occasionally add a backup copy or an extra
data file, etc).

I contemplated ubifs on NAND devices as an alternative
when starting to play with ARM-based devices, and lost the reliability
and ability to fix. Switching back to the proven ext2 completely solved
the issues in the end.

Ubifs is nice when you need a real read/write FS,
but most small devices do not need wear leveling or any of such nice
features. When you just write 1-10 times a year, other solutions are
fine enough. Using mtdblock directly is not reliable because of bad
blocks which come from time to time. If your FS happens to be located
on one of them, you're screwed. UBI solves such issues and ubiblock
provides a nice interface for this.
""

I guess we could have some UBI parameter to enable this support,
and print a very noisy message to warn users about potential
device wear out -- naively assuming users read messages...
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar

Re: ubiblock RW

[Ezequiel Garcia]

On 25 March 2016 at 17:50, Ezequiel Garcia
<ezequiel@vanguardiasur.com.ar> wrote:
> On 25 Mar 01:51 PM, Artem Bityutskiy wrote:
>> On Thu, 2016-03-24 at 18:26 -0300, Ezequiel Garcia wrote:
>> > > > Richard, what do you think?
>> > > I'm definitely not fond of adding write support to ubiblock without
>> > > turning it into a proper FTL.
>> > > Otherwise it will be abused and will cause serious damage.
>> > >
>> > I'm not sure this statement makes much sense without actual numbers.
>>
>> Ezequel,
>>
>> could you re-summarize how the write support would be implemented? Read
>> entire LEB, modify data block (512 bytes), atomically write the LEB?
>> This would not perform well, but would probably work.
>>
>
> Yes, I was thinking in using atomic LEB change. The old write-support
> was implemented with a 1-LEB cache vmalloced at open, and freed at release.
>
> The flash device is written when the write cache is flushed on:
>   * block device release (detach)
>   * a different than cached leb is accessed (either through read or write)
>   * io-barrier is received through a REQ_FLUSH request
>
> It was expected that the block I/O scheduler would help mitigate
> the effects of a regular block oriented filesystem on flash sector
> erasecount.
>
> However, most likely UBIFS will do a far better job at preserving
> flash wear than any block oriented filesystem.
>
>> Or you want to avoid atomic LEB change and just erase the LEB and write
>> the entire LEB with the updated contents? This would probably be a bit
>> faster, but not power-cut safe.
>>
>
> Not sure dropping power-cut safeness a realistic option. I'd say
> most -if not all- users will want to be power-cut safe at all costs.
>
> Let me quote a mail here from Willy [1]:
>
> ""
> [..] I've been using ext2 on x86-based hardware and compact flash for
> something like 10 years with a great success (easy to mount, easy to
> fix, easy to save, easy to occasionally add a backup copy or an extra
> data file, etc).
>
> I contemplated ubifs on NAND devices as an alternative
> when starting to play with ARM-based devices, and lost the reliability
> and ability to fix. Switching back to the proven ext2 completely solved
> the issues in the end.
>
> Ubifs is nice when you need a real read/write FS,
> but most small devices do not need wear leveling or any of such nice
> features. When you just write 1-10 times a year, other solutions are
> fine enough. Using mtdblock directly is not reliable because of bad
> blocks which come from time to time. If your FS happens to be located
> on one of them, you're screwed. UBI solves such issues and ubiblock
> provides a nice interface for this.
> ""
>
> I guess we could have some UBI parameter to enable this support,
> and print a very noisy message to warn users about potential
> device wear out -- naively assuming users read messages...

Forgot to add Willy's quote:

[1] http://lists.infradead.org/pipermail/linux-mtd/2014-February/051909.html

-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

Re: ubiblock RW

[Richard Weinberger]

Am 25.03.2016 um 21:50 schrieb Ezequiel Garcia:
> I guess we could have some UBI parameter to enable this support,
> and print a very noisy message to warn users about potential
> device wear out -- naively assuming users read messages...

As I wrote in my previous mail, I think a new parameter for the ubiblock
tool would do the job.
I'd default ubiblock to RO and via the ubiblock tool you can enable RW mode.
...which would also trigger a warning.

What I'd like to avoid is a kernel command line or a Kconfig option to make
RW default. If someone *really* wants RW she has to run ubiblock --enable-rw....
in userspace. This should even work for block filesystems on top of UBI
as root fs as you can remount them later RW.

Sounds like a plan?

Thanks,
//richard

Re: ubiblock RW

[Willy Tarreau]

On Fri, Mar 25, 2016 at 10:25:17PM +0100, Richard Weinberger wrote:
> Am 25.03.2016 um 21:50 schrieb Ezequiel Garcia:
> > I guess we could have some UBI parameter to enable this support,
> > and print a very noisy message to warn users about potential
> > device wear out -- naively assuming users read messages...
> 
> As I wrote in my previous mail, I think a new parameter for the ubiblock
> tool would do the job.
> I'd default ubiblock to RO and via the ubiblock tool you can enable RW mode.
> ...which would also trigger a warning.
> 
> What I'd like to avoid is a kernel command line or a Kconfig option to make
> RW default. If someone *really* wants RW she has to run ubiblock --enable-rw....
> in userspace. This should even work for block filesystems on top of UBI
> as root fs as you can remount them later RW.
> 
> Sounds like a plan?

I would see something a little bit better (from a user perspective), though
I don't know if it's possible. It would be nice to mark the UBI image RO/RW
when it is created via ubiformat. That would be a bit stored on the ubiblock
itself. That way the decision is taken at creation time and is not changed
later (or only using a specific tool). Note that it is very possible I'm
missing something important, but you get the idea.

Thanks,
Willy

Re: ubiblock RW

[Richard Weinberger]

Am 26.03.2016 um 07:01 schrieb Willy Tarreau:
> On Fri, Mar 25, 2016 at 10:25:17PM +0100, Richard Weinberger wrote:
>> Am 25.03.2016 um 21:50 schrieb Ezequiel Garcia:
>>> I guess we could have some UBI parameter to enable this support,
>>> and print a very noisy message to warn users about potential
>>> device wear out -- naively assuming users read messages...
>>
>> As I wrote in my previous mail, I think a new parameter for the ubiblock
>> tool would do the job.
>> I'd default ubiblock to RO and via the ubiblock tool you can enable RW mode.
>> ...which would also trigger a warning.
>>
>> What I'd like to avoid is a kernel command line or a Kconfig option to make
>> RW default. If someone *really* wants RW she has to run ubiblock --enable-rw....
>> in userspace. This should even work for block filesystems on top of UBI
>> as root fs as you can remount them later RW.
>>
>> Sounds like a plan?
> 
> I would see something a little bit better (from a user perspective), though
> I don't know if it's possible. It would be nice to mark the UBI image RO/RW
> when it is created via ubiformat. That would be a bit stored on the ubiblock
> itself. That way the decision is taken at creation time and is not changed
> later (or only using a specific tool). Note that it is very possible I'm
> missing something important, but you get the idea.

ubiblock is just a layer above an UBI volumes.
We could add a new UBI volume flag for RW ubiblock.

Artem? Ezequiel?

Thanks,
//richard

Re: ubiblock RW

[Artem Bityutskiy]

On Mon, 2016-03-28 at 00:01 +0200, Richard Weinberger wrote:
> Am 26.03.2016 um 07:01 schrieb Willy Tarreau:
> > 
> > On Fri, Mar 25, 2016 at 10:25:17PM +0100, Richard Weinberger wrote:
> > > 
> > > Am 25.03.2016 um 21:50 schrieb Ezequiel Garcia:
> > > > 
> > > > I guess we could have some UBI parameter to enable this
> > > > support,
> > > > and print a very noisy message to warn users about potential
> > > > device wear out -- naively assuming users read messages...
> > > As I wrote in my previous mail, I think a new parameter for the
> > > ubiblock
> > > tool would do the job.
> > > I'd default ubiblock to RO and via the ubiblock tool you can
> > > enable RW mode.
> > > ...which would also trigger a warning.
> > > 
> > > What I'd like to avoid is a kernel command line or a Kconfig
> > > option to make
> > > RW default. If someone *really* wants RW she has to run ubiblock
> > > --enable-rw....
> > > in userspace. This should even work for block filesystems on top
> > > of UBI
> > > as root fs as you can remount them later RW.
> > > 
> > > Sounds like a plan?
> > I would see something a little bit better (from a user
> > perspective), though
> > I don't know if it's possible. It would be nice to mark the UBI
> > image RO/RW
> > when it is created via ubiformat. That would be a bit stored on the
> > ubiblock
> > itself. That way the decision is taken at creation time and is not
> > changed
> > later (or only using a specific tool). Note that it is very
> > possible I'm
> > missing something important, but you get the idea.
> ubiblock is just a layer above an UBI volumes.
> We could add a new UBI volume flag for RW ubiblock.

You can add a per-volume R/O flag if needed, yes. Expose it to user-
space. This may be a useful thing irrespectively. I am not sure how it
helps with ubiblock though.

Ideally, the ubiblock R/W enabled flag should be stored in ubiblock,
not in UBI, not in MTD, because you want ubiblock to have full control
over it. You do not want a user go and change the flag via the UBI
interface whenever the user feels like, right?

To have this kind of flag in ubiblock, it needs an on-flash superblock
or something. If you are not going to introduce it, which I believe is
the case, then the only option left in my opinion is a ubiblock module
parameter.

If I am a ubiblock user who needs the write support, and this naive
write support is good enough for me, I want it enabled by default on my
product. A module parameter with a sound name like 'dangerous-write-
support' or something would work fine for me.

Artem.

Re: ubiblock RW

[Willy Tarreau]

On Mon, Mar 28, 2016 at 09:56:53AM +0300, Artem Bityutskiy wrote:
> You can add a per-volume R/O flag if needed, yes. Expose it to user-
> space. This may be a useful thing irrespectively. I am not sure how it
> helps with ubiblock though.
> 
> Ideally, the ubiblock R/W enabled flag should be stored in ubiblock,
> not in UBI, not in MTD, because you want ubiblock to have full control
> over it. You do not want a user go and change the flag via the UBI
> interface whenever the user feels like, right?
> 
> To have this kind of flag in ubiblock, it needs an on-flash superblock
> or something. If you are not going to introduce it, which I believe is
> the case, then the only option left in my opinion is a ubiblock module
> parameter.
> 
> If I am a ubiblock user who needs the write support, and this naive
> write support is good enough for me, I want it enabled by default on my
> product. A module parameter with a sound name like 'dangerous-write-
> support' or something would work fine for me.

Thanks Artem for the explanation. I think it all makes sense indeed.

Willy