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

[Edward Shishkin <edward.shishkin@gmail.com>]

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,