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:
signature.asc
Description: This is a digitally signed message part
