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 13:32:43 +0200 (CEST)
From:	Lukas Czerner <lczerner@...hat.com>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
cc:	Lukas Czerner <lczerner@...hat.com>,
	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

On Tue, 24 May 2011, OGAWA Hirofumi wrote:

> Lukas Czerner <lczerner@...hat.com> writes:
> 
> >> 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.
> >> 
> >
> > What ? No, of course not. As I said, just go through 1G worth of filesystem
> > blocks skipping metadata. However we do have a special case when we
> > adjust start and len according to the first data block (which is only
> > the case of 1024B blocksize).
> >
> > 	if (start < first_data_blk) {
> > 		len -= first_data_blk - start;
> > 		start = first_data_blk;
> > 	}
> >
> > Which means that we just skip the first block (or whatever first data
> > block is). And this is the same as skipping metadata.
> 
> Are you read my email? So, FAT adjust 2 blocks, ext* 1 block, and what
> is other? The middle was guaranteed as continued? So, which is end of
> blocks?

I am sorry but I am not sure what you are asking for. Just grab the size
of the file system or even better the size of underlying device (since
the filesyste would not be bigger than that) and use that.

Of course if you grab the count of filesystem blocks (and the file
system does not account for the first data block) you'll end up with len
smaller than first data block. So it might make sense to not to
decrement the len and just start from first data block since it is not
accounted for anyway. However it is not a big deal, is it ? Are you
expecting any problems with this behaviour ?

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