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.
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
