Re: [patch] reiser4: port for Linux-4.1

[Edward Shishkin <edward.shishkin@gmail.com>]

On 07/05/2015 01:53 AM, Ivan Shapovalov wrote:
> On 2015-07-04 at 15:53 +0800, Edward Shishkin wrote:
>> On 07/02/2015 07:35 AM, Ivan Shapovalov wrote:
>>> On 2015-06-30 at 10:58 +0200, Edward Shishkin wrote:
>>>> [...]
>>>> BTW, we need to do something with the "precise discard > > > extension":
>>>> http://sourceforge.net/projects/reiser4/files/patches/
>>>> It reports erase unit 512 bytes for my samsung SSD 840 EVO.
>>>> You said that this is incorrect. If so, then how to retrieve
>>>> correct
>>>> discard parameters?
>>> I was wrong about usage of `hdparm -I`. The "limit" it says about
>>> is in fact "how many 512-byte blocks worth of LBA ranges can be
>>> given
>>> to the drive in a single ATA trim command"[1].
>>>
>>> In fact, the standard (referenced below) doesn't seem to contain
>>> any references to the trim granularity, let alone to define any
>>> means
>>> to query it.
>>>
>>> So, I guess, the kernel will never tell us correct values for ATA
>>> SSDs,
>>> and the only option is direct testing at mount time.
>>
>> And how to test directly at mount time?
> Something along the lines of
> - allocate 1 MiB of contiguous space
> - fill it with non-zeros
> - for N = 1, 2, 4, ...:
>    - discard N sectors from the contiguous space
>    - check if anything in the discarded space became zero-filled
>    - if it did, infer alignnment from the first zero-filled block,
>      infer granularity from the zero-filled region size.


mkfs seems to be more suitable for this funny business


>> It seems that nobody cares about it..
> It's just ATA interface does not provide necessary data.


OK, so our precise discard extension is waiting for the
best times..

Thanks,
Edward.