linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Piergiorgio Beruto" <piergiorgio.beruto@gmail.com>
To: "'Willy Tarreau'" <w@1wt.eu>, "'Richard Weinberger'" <richard@nod.at>
Cc: 'Thomas Petazzoni' <thomas.petazzoni@free-electrons.com>,
	'Mike Frysinger' <vapier@gentoo.org>,
	'Artem Bityutskiy' <dedekind1@gmail.com>,
	'Michael Opdenacker' <michael.opdenacker@free-electrons.com>,
	linux-mtd@lists.infradead.org, 'Tim Bird' <tim.bird@am.sony.com>,
	'Ezequiel Garcia' <ezequiel.garcia@free-electrons.com>,
	'Brian Norris' <computersforpeace@gmail.com>,
	'David Woodhouse' <dwmw2@infradead.org>
Subject: RE: [PATCH 1/1] ubi: Introduce block devices for UBI volumes
Date: Sun, 9 Feb 2014 00:10:36 +0100	[thread overview]
Message-ID: <000201cf2522$fafbb770$f0f32650$@gmail.com> (raw)
In-Reply-To: <20140208230159.GC22376@1wt.eu>

Hi,
just to better explain my previous mail, I actually agree with you that it's
generally a bad idea to cut off a feature just because you don't see good
use for yourself or because it's dangerous.
The real reason to remove the RW feature, in my opinion, might be for
reducing the amount of code you have to maintain over time.

Usually I try to understand the benefits vs effort when deciding about such
things.
In this case It seems to me that the effort is not that much but I fail to
see any real use of the RW feature for myself.

I suggest to listen to other people that used ubblk before making any
decision.

Regards,
Piergiorgio

-----Original Message-----
From: Willy Tarreau [mailto:w@1wt.eu] 
Sent: Sunday, February 9, 2014 12:02 AM
To: Richard Weinberger
Cc: Ezequiel Garcia; linux-mtd@lists.infradead.org; Thomas Petazzoni; Mike
Frysinger; Artem Bityutskiy; Michael Opdenacker; Tim Bird; Piergiorgio
Beruto; Brian Norris; David Woodhouse
Subject: Re: [PATCH 1/1] ubi: Introduce block devices for UBI volumes

On Sat, Feb 08, 2014 at 11:56:02PM +0100, Richard Weinberger wrote:
> Am 08.02.2014 23:51, schrieb Willy Tarreau:
> > On Sat, Feb 08, 2014 at 10:37:19PM +0100, Richard Weinberger wrote:
> >>> +config MTD_UBI_BLOCK_WRITE_SUPPORT
> >>> +       bool "Enable write support (DANGEROUS)"
> >>> +       default n
> >>> +       depends on MTD_UBI_BLOCK
> >>> +       select MTD_UBI_BLOCK_CACHED
> >>> +       help
> >>> +          This is a *very* dangerous feature. Using a regular
block-oriented
> >>> +          filesystem might impact heavily on a flash device wear.
> >>> +          Use with extreme caution.
> >>> +
> >>> +          If in doubt, say "N".
> >>
> >> I really vote for dropping write support at all.
> > 
> > Why ? When you put a read-only filesystem there such as squashfs, 
> > the only writes you'll have will be updates, and write support will 
> > be the only way to update the filesystem. So removing write support 
> > seriously impacts the usefulness of the feature itself.
> 
> So almost everyone has to enable MTD_UBI_BLOCK_WRITE_SUPPORT?
> I thought there is another way to fill the volume with data...

I personally don't see the use of disabling write support on anything unless
the code is broken. Better emit a warning upon first write to mention that
there is limited or no wear leveling. But preventing all reasonable users
from using a useful feature just to save a few ignorant from shooting
themselves in the foot is non-sense in my opinion.

Why not disable write support to ubifs as well then, so that we're sure that
the most demanding ones will never wear their NANDs ? And why not disable
mtdblock so that nobody can mount them as ext2 ? If people can already do
bad things more easily without this code, there is no reason to remove the
feature.

Regards,
Willy

  reply	other threads:[~2014-02-08 23:11 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-29 20:38 [PATCH 0/1] ubi: Introduce block devices for UBI volumes Ezequiel Garcia
2014-01-29 20:38 ` [PATCH 1/1] " Ezequiel Garcia
2014-01-31 17:06   ` Willy Tarreau
2014-02-04 11:06     ` Ezequiel Garcia
2014-02-08 16:50       ` Ezequiel Garcia
2014-02-08 21:37   ` Richard Weinberger
2014-02-08 22:51     ` Willy Tarreau
2014-02-08 22:56       ` Richard Weinberger
2014-02-08 23:01         ` Willy Tarreau
2014-02-08 23:10           ` Piergiorgio Beruto [this message]
2014-02-08 23:13           ` Richard Weinberger
2014-02-08 23:15             ` Willy Tarreau
2014-02-08 23:25               ` Richard Weinberger
2014-02-08 23:37                 ` Willy Tarreau
2014-02-09  0:17                   ` Richard Weinberger
2014-02-09  7:51                     ` Willy Tarreau
2014-02-10  2:48                       ` Ezequiel Garcia
2014-02-10  7:35                         ` Artem Bityutskiy
2014-02-10  8:27                           ` Ezequiel Garcia
2014-02-10  8:46                             ` Willy Tarreau
2014-02-10 14:20                               ` Ezequiel Garcia
2014-02-10 14:41                                 ` Richard Weinberger
2014-02-10 14:50                                 ` Artem Bityutskiy
2014-02-10 14:52                                   ` Bityutskiy, Artem
2014-02-10 16:15                                     ` Willy Tarreau
2014-02-10 14:53                                   ` Bityutskiy, Artem
2014-02-10 18:48                                   ` Ezequiel Garcia
     [not found]                                     ` <a86d653a-9e3b-46dc-9ec8-94a9c1099bec@email.android.com>
2014-02-10 21:43                                       ` Willy Tarreau
2014-02-11  8:37                                         ` Geert Uytterhoeven
2014-02-11  9:05                                           ` Willy Tarreau
2014-02-11  9:35                                             ` Ezequiel Garcia
2014-02-11  9:43                                           ` Peter Korsgaard
2014-02-11 10:21                                             ` Geert Uytterhoeven
2014-02-10 22:37                                     ` Thomas Petazzoni
     [not found]                                       ` <de976336-3144-4f21-859b-d1a37fc3d811@email.android.com>
2014-02-10 22:46                                         ` Thomas Petazzoni
     [not found]                                           ` <a3fc06a8-c809-4687-9da4-015bd8dd29e8@email.android.com>
2014-02-10 23:01                                             ` Thomas Petazzoni
2014-02-10 23:19                                           ` Ezequiel Garcia
2014-02-10  8:50                             ` Artem Bityutskiy
2014-02-08 23:05         ` Piergiorgio Beruto
2014-02-08 23:13           ` Willy Tarreau
2014-02-10  8:42       ` Thomas Petazzoni
2014-02-10  8:51         ` Willy Tarreau
2014-02-10  1:29     ` Ezequiel Garcia
2014-02-10  7:53       ` Richard Weinberger
2014-02-10  8:12         ` Ezequiel Garcia
2014-02-10  8:24           ` Artem Bityutskiy
2014-02-10  8:37             ` Willy Tarreau
2014-02-10  8:50             ` Ezequiel Garcia
2014-02-09 22:56   ` Richard Weinberger
2014-02-10  2:36     ` 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='000201cf2522$fafbb770$f0f32650$@gmail.com' \
    --to=piergiorgio.beruto@gmail.com \
    --cc=computersforpeace@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael.opdenacker@free-electrons.com \
    --cc=richard@nod.at \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=tim.bird@am.sony.com \
    --cc=vapier@gentoo.org \
    --cc=w@1wt.eu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).