Messages in this thread | | | From | OGAWA Hirofumi <> | Subject | Re: [PATCH v6] fat: Batched discard support for fat | Date | Tue, 24 May 2011 23:19:00 +0900 |
| |
Lukas Czerner <lczerner@redhat.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@mail.parknet.co.jp>
| |