All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>,
	Benson Young <benson6877@gmail.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	David Gstir <david@sigma-star.at>
Subject: Re: ubiblock RW
Date: Thu, 24 Mar 2016 21:38:05 +0100	[thread overview]
Message-ID: <56F4502D.3030902@nod.at> (raw)
In-Reply-To: <CAAEAJfB42GY9kGDBvacpKNgtAt3Kp1bE6rfprm_A_WiwR_cXGg@mail.gmail.com>

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

  reply	other threads:[~2016-03-24 20:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CABJ+KKu2RJuHXE3LpmzSYtE0i57sHDUHWOxPxufCP94RTa=eBA@mail.gmail.com>
2016-03-24 14:23 ` ubiblock RW Ezequiel Garcia
2016-03-24 20:38   ` Richard Weinberger [this message]
2016-03-24 21:26     ` Ezequiel Garcia
2016-03-24 21:39       ` Willy Tarreau
2016-03-25 20:28         ` Richard Weinberger
2016-03-25 11:51       ` Artem Bityutskiy
2016-03-25 20:50         ` Ezequiel Garcia
2016-03-25 20:51           ` Ezequiel Garcia
2016-03-25 21:25           ` Richard Weinberger
2016-03-26  6:01             ` Willy Tarreau
2016-03-27 22:01               ` Richard Weinberger
2016-03-28  6:56                 ` Artem Bityutskiy
2016-03-28  8:17                   ` Willy Tarreau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56F4502D.3030902@nod.at \
    --to=richard@nod.at \
    --cc=benson6877@gmail.com \
    --cc=david@sigma-star.at \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.