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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAH9JG2UDKD-tZPo-OiQmiheNvPqPE2o_cTEbc9M9Uu02HB6hcw@mail.gmail.com>
Date:	Wed, 31 Aug 2011 22:02:53 +0900
From:	Kyungmin Park <kmpark@...radead.org>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc:	Lukas Czerner <lczerner@...hat.com>, 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

Hi Ogawa,

Do you still object to merge batched discard support on fat?

If the current batched discard concept doesn't changed, it can't merge it?

BTW please consider that it's not functional feature at fat
filesystem. it's hint for device which reduce the merge operational
internally and it doesn't effect the filesystem operation itself.

Thank you,
Kyungmin Park

On Tue, May 24, 2011 at 11:19 PM, OGAWA Hirofumi
<hirofumi@...l.parknet.co.jp> wrote:
> Lukas Czerner <lczerner@...hat.com> writes:
>
>>> What is size of file system or underlying devices? You force to find the
>>> device which target FS is using? Even if you can get size of underlying
>>> devices, you force to user to insane loop in size of devices?
>>
>> Look, I do not have time to argue with you forever and I do not even
>> understand what is your point. Just go and read other filesystems
>> implementation of FITRIM (ext4,ext3,xfs,btrfs?) and you'll see what you
>> need to do.
>>
>> If you do not want to get the file system size, then FINE! just pass the
>> damn UULONG_MAX as length. I have no clue what insane loop are you
>> talking about! It is *easy* just discard the whole thing (with
>> UULONG_MAX) or, if you want to do it per-partes, then do it as long as
>> it does not return EINVAL, once it does you know that your "start" is
>> out of the filesystem and you are done!
>
> You are not even understanding current implementations. See
> ext3_trim_fs(), and ext4_trim_fs().
>
> What happen if "start" was outside of max_blks:
>
> ext3 returns 0
> ext4 returns EINVAL
>
> What means "start" is 0
>
> ext3 maps to 1
> ext4 just remove 0 from request
>
> I missing something?
>
>>> Why can you guarantee it's not big deal in design? Why can't you admit
>>> userland can't make optimized loop?
>>
>> And what do you mean by that ?
>>
>> -Lukas
>
> --
> 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/