linux-ext4 - Re: [PATCH] ext4: Adjust trim start with first_data

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110204054012.GD2623@thunk.org>
Date:	Fri, 4 Feb 2011 00:40:12 -0500
From:	Ted Ts'o <tytso@....edu>
To:	Tao Ma <tm@....ma>
Cc:	linux-ext4@...r.kernel.org, Lukas Czerner <lczerner@...hat.com>
Subject: Re: [PATCH] ext4: Adjust trim start with first_data_block.

On Fri, Jan 21, 2011 at 10:05:07PM +0800, Tao Ma wrote:
> From: Tao Ma <boyu.mt@...bao.com>
> 
> As we have make the consense in the e-mail[1], the trim start should
> be added with first_data_block. So this patch fulfill it and remove
> the check for start < first_data_block.

> 
> [1] http://www.spinics.net/lists/linux-ext4/msg22737.html
> 

Sorry, I was away at Linux.conf.au and didn't have a chance to respond
this.

Fundamentally I think we need to understand what the arguments to the
trim ioctl is supposed to *mean*.  Are they supposed to be physical
block numbers, or some thing else?  If we just bump everything by the
first_data_block, (which is non-zero only for the 1k case), that will
screw up the length argument, because the userspace program isn't
going to know that (a) the file system is using 1k blocks, and (b) on
ext2/3/4 that means that first_data_block is 1.

So instead of saying that the arguments to trim mean "the data blocks"
--- which is a concept that doesn't really have any meaning to the
caller of the trim ioctl, without forcing it to know a lot more about
the physical layout of filesystems, I think the argument to trim
should be the physical block numbers.

And just as we don't trim blocks that contain data that should be
saved, we should just simply not trim block #0 (the boot block) and
and block #1 (the superblock) on 1k block filesystems, and not trim
block #0 (the boot block as well as the superblock) on 4k block
filesystems.  But we shouldn't be doing this by taking block number
passed to trim and just adding first_data_block to it.

I know a patch to do that has already merged into ext3, but with the
indulgence of the folks on linux-ext4, could we reopen this question?

Thanks,

						- 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