linux-ext4 - Re: [RESEND] [PATCH 2/2 v2] e2fsck: Do not forget to discard last block group

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, 27 Feb 2012 19:33:19 +0100 (CET)
From:	Lukas Czerner <lczerner@...hat.com>
To:	"Ted Ts'o" <tytso@....edu>
cc:	Lukas Czerner <lczerner@...hat.com>, linux-ext4@...r.kernel.org,
	psusi@...ntu.com, sandeen@...hat.com
Subject: Re: [RESEND] [PATCH 2/2 v2] e2fsck: Do not forget to discard last
 block group

On Mon, 27 Feb 2012, Ted Ts'o wrote:

> On Mon, Feb 27, 2012 at 06:57:48PM +0100, Lukas Czerner wrote:
> > 
> > exactly. I am trying to benefit from the same optimization e2fsck does.
> > If the BLOCK_UNINIT is set then we can easily leave that group be and
> > save some time. Even though that might not be a huge problem with small
> > file systems, or some *really* fast SSD's, you'll certainly notice it on
> > huge thin-provisioned storage, or generally any bigger discard capable
> > device.
> 
> Well, maybe then the right answer is that we make it an option.  There
> *are* times when you might want to issue a discard for every single
> unused block, even if you think it may have already been discarded.

I would really like to avoid another option if we can avoid it.

> 
> For example, there are some brain-damaged thin-provisioned storage
> boxes that ignore discards that are smaller than 4 megabytes, and then
> only discard on 4 megabyte aligned boundaries.  So even though the
> space might have been previously discarded, one of the reasons why you
> might want e2fsck -E discard to force a discard of the entire block
> group is because the space might not have been released if the
> previous TRIM commands (perhaps issued as various 1mb files were
> deleted) didn't obey whatever arbitrary restrictions that are imposed
> by the storage device.

I have to admit I do not really understand the example. If the block
group is flagged with BLOCK_UNINIT there was never any file allocated
from that group right ? Also, mke2fs issues initial full device discard
before the file system creation. So if you have this brain-damaged
thin-provisioned storage, discarding BLOCK_UNINIT groups would not
actually bring you anything.

> 
> I'll agree that as a default, the optimization might make sense.  But
> it would be good if there's a way to really to bypass the optimization
> and issue the discard for every single unused block.

Well, if the user really want to discard everything which is free in the
file system, then there is still wiper.sh which is not fs specific.
However it would have some unneeded consequences.

> 
>     	      	      	  	       - 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