linux-ext4 - Re: [PATCH] mke2fs: restore verbose message for BLKDISCARD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 11 Mar 2013 15:18:38 +0100 (CET)
From:	Lukáš Czerner <lczerner@...hat.com>
To:	Eric Sandeen <sandeen@...hat.com>
cc:	"Theodore Ts'o" <tytso@....edu>,
	Stephen Warren <swarren@...dotorg.org>,
	Lukáš Czerner <lczerner@...hat.com>,
	Chris Ball <cjb@...top.org>, linux-ext4@...r.kernel.org,
	Stephen Warren <swarren@...dia.com>
Subject: Re: [PATCH] mke2fs: restore verbose message for BLKDISCARD

On Mon, 11 Mar 2013, Eric Sandeen wrote:

> Date: Mon, 11 Mar 2013 09:08:20 -0500
> From: Eric Sandeen <sandeen@...hat.com>
> To: Theodore Ts'o <tytso@....edu>
> Cc: Stephen Warren <swarren@...dotorg.org>,
>     Lukáš Czerner <lczerner@...hat.com>, Chris Ball <cjb@...top.org>,
>     linux-ext4@...r.kernel.org, Stephen Warren <swarren@...dia.com>
> Subject: Re: [PATCH] mke2fs: restore verbose message for BLKDISCARD
> 
> On 3/8/13 1:00 PM, Theodore Ts'o wrote:
> > I hate to suggest this, but there's so many crappy devices out there
> > that I'm wondering if we need to figure out some way of maintaining a
> > black list of devices that don't handle discard properly.  For
> > example, the Sandisk U100 advertises a max discard granularity of 512
> > bytes, but I've been advised that if you don't use a discard
> > granularity of 256k, aligned on 256k, you'll be very, very, sorry.
> 
> > It sounds like Stephen's device is probably an example of Yet Another
> > Busted Trim implementation.  The problem is that manufacturers will be
> > releasing more broken products faster than we can update a blacklist
> > in the kernel.  So any blacklist would have to be maintained online on
> > the web, and dynamically updated by distro installers.   :-(
> 
> Yeah I think it may be time for a blacklist.
> 
> TBH I think we should revisit discard-at-mkfs-time by default as well.
> 
> It seemed like a decent idea at the time, but now we have handy
> fstrim as well as online/dynamic/realtime trim, and trim at mkfs
> makes mke2fs completely un-doable in the event of fat fingers.

However that will make things even worse when someone uses it on
such device, than simply realising the problem on mkfs time. Sure,
there are buggy or crappy devices out there, but that's not we want
to optimize for right ?

Regarding the 'fat fingers' point I am starting to thing that
refusing to create the file system if we found any old signature
(like xfs does) would really be a good thing to have. In order not
to break scripts we can fall back to the old behaviour if we find
out that there is not any interactive input attached (we're running
from the script).

-Lukas

> 
> -Eric
> 
> 
> > 
> >     	     		 	    	   		 - Ted
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> > the body of a message to majordomo@...r.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
>