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.
[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,
--
Ivan Shapovalov / intelfx /
Attachment:
signature.asc
Description: This is a digitally signed message part
