Re: [PATCH v6] fat: Batched discard support for fat

[Kyungmin Park]

On Wed, Mar 30, 2011 at 10:50 PM, Lukas Czerner <lczerner@xxxxxxxxxx> wrote:
> On Wed, 30 Mar 2011, Arnd Bergmann wrote:
>
>> On Monday 28 March 2011, Kyungmin Park wrote:
>> > So you will go through (blocks, bytes...) 0 -> 20
>> >
>> >   OOOO==O===OO===OOOOO==O===O===OOOOOOO===
>> >   ^                   ^
>> >   0                   20
>> >
>> > So, you will call discard on extents:
>> >
>> > 0-3
>> > You'll skip 6 because is smaller than minlen
>> > 10-11
>> > 15-19
>> >
>> > instead of
>> >
>> > 0-3
>> > 10-11
>> > 15-19
>> > 30-36
>>
>> Sorry for joining the discussion late, but shouldn't you also pass
>> the alignment of the discards?
>>
>> FAT is typically used on cheap media that have very limited support
>> for garbage-collection, such as eMMC or SD cards.
>>
>> On most SDHC cards, you only ever want to issue discard on full erase
>> blocks (allocation units per spec), typically sized 4 MB.
>
> I was not aware of the fact that SD cards (etc..) does have garbage
> collection of some sort, or that they even have support discard, since I
> thought that we have only TRIM,UNAMP/WRITE_SAME comands for SATA or SCSI
> drives.
>
> Or is there some sort of kernel mechanism doing garbage collection such
> is this for the cheap media ?
>
>>
>> If you just pass the minimum length, the file system could end up
>> erasing a 4 MB section that spans two half erase blocks, or it
>> could span a few clusters of the following erase block, both of
>> which is not desirable from a performance point of view.
>
> Does those cards export such information correctly ?

Each chip vendor knows it exactly and usually can't tell it outside officially.
but it's not big as you think. also if the request size is under trim
size, then it's discarded internally.
I mean do nothing at firmware level.

Thank you,
Kyungmin Park

>
>>
>> On other media, you have the same problem inside an erase block:
>> These might be able to discard parts of an erase block efficiently,
>> but normally not less than a flash page (typically 8 to 32 KB).
>
> Well I have tested several SSD's and thinly provisioned devices, but I
> have not seen any strange behaviour, other than it was terribly
> unefficient to do so. See my results here:
>
> http://people.redhat.com/lczerner/discard/test_discard.html
>
> the fact is that I have not tried discard size smaller than 4K, since
> this is the most usual block size for the filesystem.
>
>>
>> Again, you don't want to discard partial pages in this case, and
>> that is much more important than discarding a large number of pages
>> because it would result in an immediate copy-on-write operation.
>>
>> Further, when you erase some pages inside of an erase block, you
>> probably should not span multiple erase blocks but instead issue
>> separate requests for each set of pages in one erase block.
>
> Does it mean that we should not issue bigger discards that erase block ?
> That does not sound good given my test results. Or maybe I misunderstood
> your point ?
>
>>
>>       Arnd
>>
>>       Arnd
>>
>
> Thanks!
> -Lukas
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/