On 07/02/2015 07:35 AM, Ivan Shapovalov wrote:
On 2015-06-30 at 10:58 +0200, Edward Shishkin wrote:
On 06/30/2015 10:06 AM, Ivan Shapovalov wrote:
On 2015-06-30 at 09:30 +0200, Edward Shishkin wrote:
On 06/30/2015 09:13 AM, Ivan Shapovalov wrote:
On 2015-06-30 at 01:54 +0800, Edward Shishkin wrote:
Oh, bad
generic_write_checks() doesn't change offset now,
please, ignore this patch..
Hi,
Hello.
it does change it, but in struct kiocb instance, but we keep
using
initial "off".
i'm trying to port file_operations' ->write() to ->write_iter()
right
Hmm. You'll need to modify ->write() of both file plugins -
it's not simple, esp. for cryptcompress, which performs writes by
chunks (4, 8, ... 64K)
Yeah, I understand. However, it doesn't seem too complex. It's
simply
iov_iter* instead of a char*+size_t. I just need to grok how does
the
page cache work (wrt. "faulting in" pages, flushing caches, error
handling, etc).
I'm now trying to read the generic code together with btrfs'
implementation, compare bit-by-bit and implement the same in
reiser4.
now, FTR. The obvious fix (assign back ki_pos to off) is too
ugly
:)
may be just create a static inline function
reiser4_write_check() ?
{
...
generic_write_check();
*off = iocb.ki_pos;
}
Sure, it will work, but right now, as everything in vfs moves
towards
*_iter methods, I guess there could be some sense in moving to
those as
well...
Yes, I understand that vfs is a fast-moving target, but why not?
I afraid it'll get stuck in the queue "for review"..
Then let's say that we have an "experimental"/"unreviewed" branch :)
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?
It seems that nobody cares about it..
E.g. I have the following (samsung SSD 840 EVO):
reiser4: sdb1: enable discard support (erase unit 512 bytes, alignment 0
bytes)
Thanks,
Edward.
[1]: ATA8-ACS3 (nevar.pl/pliki/ATA8-ACS-3.pdf), 7.16.7.55
"IDENTIFY DEVICE" - "Input From the Device to the Host Data
Structure" - "7.16.7.55 Word 105: Maximum number of 512-byte
blocks of LBA Range Entries per DATA SET MANAGEMENT command".
Thanks,
--
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
