From: Artem Bityutskiy <dedekind1@gmail.com>
To: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Ezequiel Garcia <elezegarcia@gmail.com>,
Michael Opdenacker <michael.opdenacker@free-electrons.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-mtd@lists.infradead.org, Tim Bird <tim.bird@am.sony.com>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [RFC/PATCH 0/1] ubi: Add ubiblock driver
Date: Fri, 30 Nov 2012 13:25:49 +0200 [thread overview]
Message-ID: <1354274749.30168.100.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <20121121110022.35db364f@skate>
[-- Attachment #1: Type: text/plain, Size: 980 bytes --]
On Wed, 2012-11-21 at 11:00 +0100, Thomas Petazzoni wrote:
> While I think the original ubiblk that was read-only made sense to
> allow the usage of read-only filesystems like squashfs, I am not sure
> a
> read/write ubiblock is useful.
>
> Using a standard block read/write filesystem on top of ubiblock is
> going
> to cause damage to your flash. Even though UBI does wear-leveling,
> your
> standard block read/write filesystem will think it has 512 bytes block
> below him, and will do a crazy number of writes to small blocks. Even
> though you have a one LEB cache, it is going to be defeated quite
> strongly by the small random I/O of the read/write filesystem.
Well, in practice normal file-system do 4K-aligned I/O, without crazy
things, and try to do I/O sequentially.
>
> I am not sure letting people use read/write block filesystems on top
> of
> flashes, even through UBI, is a good idea.
Why not?
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Ezequiel Garcia <elezegarcia@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-mtd@lists.infradead.org,
David Woodhouse <dwmw2@infradead.org>,
Tim Bird <tim.bird@am.sony.com>,
Michael Opdenacker <michael.opdenacker@free-electrons.com>
Subject: Re: [RFC/PATCH 0/1] ubi: Add ubiblock driver
Date: Fri, 30 Nov 2012 13:25:49 +0200 [thread overview]
Message-ID: <1354274749.30168.100.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <20121121110022.35db364f@skate>
[-- Attachment #1: Type: text/plain, Size: 980 bytes --]
On Wed, 2012-11-21 at 11:00 +0100, Thomas Petazzoni wrote:
> While I think the original ubiblk that was read-only made sense to
> allow the usage of read-only filesystems like squashfs, I am not sure
> a
> read/write ubiblock is useful.
>
> Using a standard block read/write filesystem on top of ubiblock is
> going
> to cause damage to your flash. Even though UBI does wear-leveling,
> your
> standard block read/write filesystem will think it has 512 bytes block
> below him, and will do a crazy number of writes to small blocks. Even
> though you have a one LEB cache, it is going to be defeated quite
> strongly by the small random I/O of the read/write filesystem.
Well, in practice normal file-system do 4K-aligned I/O, without crazy
things, and try to do I/O sequentially.
>
> I am not sure letting people use read/write block filesystems on top
> of
> flashes, even through UBI, is a good idea.
Why not?
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-11-30 11:25 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-20 22:39 [RFC/PATCH 0/1] ubi: Add ubiblock driver Ezequiel Garcia
2012-11-21 5:28 ` Ricard Wanderlof
2012-11-21 9:56 ` Thomas Petazzoni
2012-11-21 10:00 ` Ricard Wanderlof
2012-11-21 10:05 ` Thomas Petazzoni
2012-11-24 21:02 ` Ezequiel Garcia
2012-11-25 7:36 ` Shmulik Ladkani
2012-11-30 11:24 ` Artem Bityutskiy
2012-12-02 17:39 ` Shmulik Ladkani
2012-12-03 0:58 ` Ezequiel Garcia
2012-12-03 19:33 ` Ezequiel Garcia
2012-12-03 21:03 ` Shmulik Ladkani
2012-11-30 11:18 ` Artem Bityutskiy
2012-11-30 11:15 ` Artem Bityutskiy
2012-11-21 10:00 ` Thomas Petazzoni
2012-11-21 10:00 ` Thomas Petazzoni
2012-11-21 10:42 ` Ezequiel Garcia
2012-11-21 10:42 ` Ezequiel Garcia
2012-11-30 11:25 ` Artem Bityutskiy [this message]
2012-11-30 11:25 ` Artem Bityutskiy
2012-11-30 11:08 ` Artem Bityutskiy
2012-11-30 11:08 ` Artem Bityutskiy
2012-11-30 20:43 ` Ezequiel Garcia
2012-11-30 20:43 ` Ezequiel Garcia
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=1354274749.30168.100.camel@sauron.fi.intel.com \
--to=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=elezegarcia@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=michael.opdenacker@free-electrons.com \
--cc=thomas.petazzoni@free-electrons.com \
--cc=tim.bird@am.sony.com \
/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.