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

[Ivan Shapovalov <intelfx100@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]

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.

> It seems that nobody cares about it..

It's just ATA interface does not provide necessary data.

-- 
Ivan Shapovalov / intelfx /

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 213 bytes --]