linux-kernel - Re: [PATCH v6] fat: Batched discard support for fat

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]

Date:	Tue, 24 May 2011 19:07:25 +0900
From:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:	Lukas Czerner <lczerner@...hat.com>
Cc:	Kyungmin Park <kmpark@...radead.org>,
	Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v6] fat: Batched discard support for fat

Lukas Czerner <lczerner@...hat.com> writes:

>> No, no. Userland will know max-length from statvfs, right? So, let's
>> assume it is 100 (->f_blocks) * 1024 (->f_bsize).
>
> You do not need to know the filesystem size to do the discard, it should
> be adjusted within the kernel. Just specify ULLONG_MAX as a length. See
> fstrim tool in util-linux-ng.
>
>> 
>> Now, userland know about max length, 102400, ok? Let's start to trim.
>> 
>> Assume, userland want to trim whole. So, userland will specify like
>> 
>> 	trim(0, 102400).
>> 
>> What happen in kernel actually?
>> 
>> Current implement doesn't map blocks. So, in the case of FAT, it adjusts
>> from 0 to 2 * 1024.
>> 
>> So, it trims between 2048 and 102400. The problem is here. FS layout is
>> actually, 2048 and (102400 + 2048). I.e. actually userland has to do
>> 
>> 	trim(2048, 102400 + 2048)
>> 
>> to specify whole. How to know 2048?
>
> You do not need to know anything in userspace. If you want to trim the
> whole filesystem you just do trim(0, ULLONG_MAX) - which is what fstrim
> does when you do not specify range. And you just skip the filesystem
> metadata obviously, regardless if they are at the beginning of the
> filesystem or in the middle. Just do whatever you need to do within your
> filesystem.
>
> What we do in ext4 is, that we convert length and start passed in struct
> fstrim_range into filesystem block units and then get the last
> allocation group and block offset within that group (we do the same for
> the start block) and we try to discard free block ranges in from staring
> block to the last block.
>
> It is really not a rocket science and since every filesystem is
> different and has different internal data structures it is up to you how
> to do this. And if you shift a block or two, it really does not matter
> as much since user-land does not know about how the filesystem block are
> laid out anyway, nor user land knows which are free and which are not.
>
> I agree that the interface is a little bit fuzzy, but that is mainly
> because it is intended to be filesystem independent and we do have a lot
> of various filesystems, so I wanted it to be as flexibile as it should,
> hence the start, len in Bytes.
>
> Hope it helped.

No. If you want to trim whole with some chunk like 1GB and periodically
(IIRC in xfstest), what do? We have to trim until ULLONG_MAX for each
1GB?

Thanks.
-- 
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/