[patch] reiser4: port for Linux-4.1

[patch] reiser4: port for Linux-4.1

[Edward Shishkin]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: reiser4-port-for-4.1.patch --]
[-- Type: text/x-patch, Size: 5044 bytes --]

. move generic_write_checks() up to the dispatcher;
. cancel_dirty_pages(), invented by akpm and me in 2007, gone:
  https://lkml.org/lkml/2015/2/20/241

Signed-off-by: Edward Shishkin <edward.shishkin@gmail.com>
---
 fs/read_write.c                          |    3 ++-
 fs/reiser4/plugin/file/cryptcompress.c   |   19 ++++++++-----------
 fs/reiser4/plugin/file/file.c            |    7 -------
 fs/reiser4/plugin/file/file_conversion.c |   18 +++++++++++++++---
 include/linux/fs.h                       |    1 +
 5 files changed, 26 insertions(+), 22 deletions(-)

--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -417,7 +417,7 @@ int rw_verify_area(int read_write, struc
 	return count > MAX_RW_COUNT ? MAX_RW_COUNT : count;
 }
 
-static ssize_t new_sync_read(struct file *filp, char __user *buf, size_t len, loff_t *ppos)
+ssize_t new_sync_read(struct file *filp, char __user *buf, size_t len, loff_t *ppos)
 {
 	struct iovec iov = { .iov_base = buf, .iov_len = len };
 	struct kiocb kiocb;
@@ -433,6 +433,7 @@ static ssize_t new_sync_read(struct file
 	*ppos = kiocb.ki_pos;
 	return ret;
 }
+EXPORT_SYMBOL(new_sync_read);
 
 ssize_t __vfs_read(struct file *file, char __user *buf, size_t count,
 		   loff_t *pos)
--- a/fs/reiser4/plugin/file/cryptcompress.c
+++ b/fs/reiser4/plugin/file/cryptcompress.c
@@ -1921,10 +1921,14 @@ static void checkout_page_cluster(struct
 		memcpy(tfm_stream_data(tc, INPUT_STREAM) + pg_to_off(i),
 		       data, in_page);
 		kunmap_atomic(data);
-
-		if (PageDirty(clust->pages[i]))
-			cancel_dirty_page(clust->pages[i], PAGE_CACHE_SIZE);
-
+		/*
+		 * modifications have been checked out and will be
+		 * committed later. Anyway, the dirty status of the
+		 * page is no longer relevant. However, the uptodate
+		 * status of the page is still relevant!
+		 */
+		if (TestClearPageDirty(clust->pages[i]))
+			account_page_cleaned(clust->pages[i], inode->i_mapping);
 		unlock_page(clust->pages[i]);
 
 		if (in_page < PAGE_CACHE_SIZE)
@@ -2875,13 +2879,6 @@ ssize_t write_cryptcompress(struct file
 	info = cryptcompress_inode_data(inode);
 	ctx = get_current_context();
 
-	result = generic_write_checks(file, &pos, &count, 0);
-  	if (unlikely(result != 0)) {
-		context_set_commit_async(ctx);
-		return result;
-	}
-  	if (unlikely(count == 0))
-		return 0;
 	result = file_remove_suid(file);
 	if (unlikely(result != 0)) {
 		context_set_commit_async(ctx);
--- a/fs/reiser4/plugin/file/file.c
+++ b/fs/reiser4/plugin/file/file.c
@@ -2101,13 +2101,6 @@ ssize_t write_unix_file(struct file *fil
 	assert("vs-947", !reiser4_inode_get_flag(inode, REISER4_NO_SD));
 	assert("vs-9471", (!reiser4_inode_get_flag(inode, REISER4_PART_MIXED)));
 
-	/* check amount of bytes to write and writing position */
-	result = generic_write_checks(file, pos, &count, 0);
-	if (result) {
-		context_set_commit_async(ctx);
-		return result;
-	}
-
 	result = file_remove_suid(file);
 	if (result) {
 		context_set_commit_async(ctx);
--- a/fs/reiser4/plugin/file/file_conversion.c
+++ b/fs/reiser4/plugin/file/file_conversion.c
@@ -28,6 +28,7 @@
  * are CS readers.
  */
 
+#include <linux/uio.h>
 #include "../../inode.h"
 #include "../cluster.h"
 #include "file.h"
@@ -519,19 +520,31 @@ static inline void done_dispatch_context
 ssize_t reiser4_write_dispatch(struct file *file, const char __user *buf,
 			       size_t count, loff_t *off)
 {
-	int result;
+	ssize_t result;
 	reiser4_context *ctx;
 	ssize_t written_old = 0; /* bytes written with initial plugin */
 	ssize_t written_new = 0; /* bytes written with new plugin */
 	struct dispatch_context cont;
 	struct inode * inode = file_inode(file);
 
+	struct iovec iov = { .iov_base = (void __user *)buf, .iov_len = count };
+	struct kiocb iocb;
+	struct iov_iter iter;
+
+	init_sync_kiocb(&iocb, file);
+	iocb.ki_pos = *off;
+	iov_iter_init(&iter, WRITE, &iov, 1, count);
+
 	ctx = reiser4_init_context(inode->i_sb);
 	if (IS_ERR(ctx))
 		return PTR_ERR(ctx);
 	current->backing_dev_info = inode_to_bdi(inode);
 	init_dispatch_context(&cont);
 	mutex_lock(&inode->i_mutex);
+
+	result = generic_write_checks(&iocb, &iter);
+	if (unlikely(result <= 0))
+		goto exit;
 	/**
 	 * First step.
 	 * Start write with initial file plugin.
@@ -556,8 +569,7 @@ ssize_t reiser4_write_dispatch(struct fi
 		warning("edward-1544",
 			"Inode %llu: file plugin conversion failed (%d)",
 			(unsigned long long)get_inode_oid(inode),
-			result);
-		context_set_commit_async(ctx);
+			(int)result);
 		goto exit;
 	}
 	reiser4_txn_restart(ctx);
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2605,6 +2605,7 @@ extern ssize_t generic_file_write_iter(s
 extern ssize_t generic_file_direct_write(struct kiocb *, struct iov_iter *, loff_t);
 extern ssize_t generic_perform_write(struct file *, struct iov_iter *, loff_t);
 
+ssize_t new_sync_read(struct file *filp, char __user *buf, size_t len, loff_t *ppos);
 ssize_t vfs_iter_read(struct file *file, struct iov_iter *iter, loff_t *ppos);
 ssize_t vfs_iter_write(struct file *file, struct iov_iter *iter, loff_t *ppos);
 

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

[Edward Shishkin]

Oh, bad
generic_write_checks() doesn't change offset now,
please, ignore this patch..

Thanks,
Edward.

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

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

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,

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
now, FTR. The obvious fix (assign back ki_pos to off) is too ugly :)


-- 
Ivan Shapovalov / intelfx /

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

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

[Edward Shishkin]

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)

> 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;
}

Thanks,
Edward.

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

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

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?

Thanks,
-- 
Ivan Shapovalov / intelfx /

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

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

[Edward Shishkin]

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"..

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?

Thanks,
Edward.

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

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 2964 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

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

[Edward Shishkin]

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,

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

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

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

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

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

[Edward Shishkin]

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.

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

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]

On 2015-07-05 at 02:33 +0800, Edward Shishkin wrote:
> On 07/05/2015 01:53 AM, Ivan Shapovalov wrote:
> > On 2015-07-04 at 15:53 +0800, Edward Shishkin wrote:
> > > 
> > > [...]
> > > 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

Yeah, sure. So... new superblock format with two extra fields?

> 
> 
> > > 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..
I hope we'll be able to merge it eventually (esp. the final patch which
accounts for non-idempotence of check-and-allocate-blocks).

Thanks,
-- 
Ivan Shapovalov / intelfx /

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

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

[Edward Shishkin]

On 07/05/2015 09:08 PM, Ivan Shapovalov wrote:
> On 2015-07-05 at 02:33 +0800, Edward Shishkin wrote:
>> On 07/05/2015 01:53 AM, Ivan Shapovalov wrote:
>>> On 2015-07-04 at 15:53 +0800, Edward Shishkin wrote:
>>>> [...]
>>>> 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
> Yeah, sure. So... new superblock format with two extra fields?


The change will be forward and backward compatible, so there is no
need in a new format. Just add two new fields to the superblock40.

Also people will want to "mount -o discard" when discard parameters
are not known. In this case I think to provide them discard_extents().
which is currently merged. Otherwise use discard_precise_extents().

Thanks,
Edward.


>
>>
>>>> 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..
> I hope we'll be able to merge it eventually (esp. the final patch which
> accounts for non-idempotence of check-and-allocate-blocks).
>
> Thanks,

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

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]

On 2015-07-05 at 21:46 +0800, Edward Shishkin wrote:
> 
> On 07/05/2015 09:08 PM, Ivan Shapovalov wrote:
> > On 2015-07-05 at 02:33 +0800, Edward Shishkin wrote:
> > > On 07/05/2015 01:53 AM, Ivan Shapovalov wrote:
> > > > On 2015-07-04 at 15:53 +0800, Edward Shishkin wrote:
> > > > > [...]
> > > > > 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
> > Yeah, sure. So... new superblock format with two extra fields?
> 
> 
> The change will be forward and backward compatible, so there is no
> need in a new format. Just add two new fields to the superblock40.

So there will be zeroes in case we mount a non-aware filesystem,
correct?

> 
> Also people will want to "mount -o discard" when discard parameters
> are not known. In this case I think to provide them 
> discard_extents().
> which is currently merged. Otherwise use discard_precise_extents().

Yeah. 
I'll do something with this after I finish porting ->write()
to ->write_iter() (or if I run into heavy problems with that).

Thanks,
-- 
Ivan Shapovalov / intelfx /

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

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

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

On 2015-07-05 at 16:06 +0200, Dušan Čolić wrote:
> On 5 Jul 2015 15:12, "Ivan Shapovalov" <intelfx100@gmail.com> wrote:
> > 
> > On 2015-07-05 at 02:33 +0800, Edward Shishkin wrote:
> > > On 07/05/2015 01:53 AM, Ivan Shapovalov wrote:

> > > > On 2015-07-04 at 15:53 +0800, Edward Shishkin wrote:
> > > > > 
> > > > > [...]
> > > > > 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
> > 
> > Yeah, sure. So... new superblock format with two extra fields?
> > 
> But what happens when someone makes an image of whole partition and 
> uses it
> on new different ssd?

Maybe we can make a tunefs.reiser4 (just) for that purpose.

-- 
Ivan Shapovalov / intelfx /

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

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

[Edward Shishkin]

On 07/05/2015 11:11 PM, Ivan Shapovalov wrote:
> On 2015-07-05 at 21:46 +0800, Edward Shishkin wrote:
>> On 07/05/2015 09:08 PM, Ivan Shapovalov wrote:
>>> On 2015-07-05 at 02:33 +0800, Edward Shishkin wrote:
>>>> On 07/05/2015 01:53 AM, Ivan Shapovalov wrote:
>>>>> On 2015-07-04 at 15:53 +0800, Edward Shishkin wrote:
>>>>>> [...]
>>>>>> 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
>>> Yeah, sure. So... new superblock format with two extra fields?
>>
>> The change will be forward and backward compatible, so there is no
>> need in a new format. Just add two new fields to the superblock40.
> So there will be zeroes in case we mount a non-aware filesystem,
> correct?


Yup.
We have a "reserved" space of 428 bytes at the end of 
format40_disk_super_block
for such purposes. This space is filled with zeros by mkfs. So 
"non-aware filesystems"
including the ones that were created by old versions of mkfs will have 
zeros there.

Edward.


>
>> Also people will want to "mount -o discard" when discard parameters
>> are not known. In this case I think to provide them
>> discard_extents().
>> which is currently merged. Otherwise use discard_precise_extents().
> Yeah.
> I'll do something with this after I finish porting ->write()
> to ->write_iter() (or if I run into heavy problems with that).
>
> Thanks,

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

[Edward Shishkin]

On 07/05/2015 11:13 PM, Ivan Shapovalov wrote:
> On 2015-07-05 at 16:06 +0200, Dušan Čolić wrote:
>> On 5 Jul 2015 15:12, "Ivan Shapovalov"<intelfx100@gmail.com>  wrote:
>>> On 2015-07-05 at 02:33 +0800, Edward Shishkin wrote:
>>>> On 07/05/2015 01:53 AM, Ivan Shapovalov wrote:
>>>>> On 2015-07-04 at 15:53 +0800, Edward Shishkin wrote:
>>>>>> [...]
>>>>>> 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
>>> Yeah, sure. So... new superblock format with two extra fields?
>>>
>> But what happens when someone makes an image of whole partition and
>> uses it
>> on new different ssd?
> Maybe we can make a tunefs.reiser4 (just) for that purpose.


tunefs utilities usually accept already existing file system as one of 
input arguments.
And it can happen that file system doesn't have enough space for 
"probing". So the
cleanest option would be to create a simple tool for probing an empty 
non-formatted
partition, and supply a script, which:

1) probes an empty partition;
2) dd;
3) updates superblock of the newly created image (by tunefs, etc) with 
proper discard
parameters.

Thanks,
Edward.
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Edward Shishkin]

Hi all,

There is a pending patch for precise discarsd, which I can not merge
because it is incomplete. Just want to know, is there any progress on
this?

So we found that calculating discard params by mkfs and storing
them in superblock is a dirty option, so I suggest to reserve a
contiguous area (1 MiB?) on disk at "mkfs -d" time (just mark it busy
in the bitmap). And calculate erase unit size and offset at mount time.
If calculation failed for some reasons, then use non-precise discard.

So, I think, we'll need one d32 field in disk superblock, which indicates
number of reserved blocks (0 means no reservation) and a pair of
definitions in disk_format40.h:

#define FORMAT40_FIRST_RESERVED_FOR_PROBING \
       ((REISER4_MASTER_OFFSET / PAGE_CACHE_SIZE) + 6)
#define FORMAT40_MAX_BLOCKS_RESERVED_FOR_PROBING

If any questions, or technical stoppers, then let me know.

Thanks,
Edward.


On 07/05/2015 05:13 PM, Ivan Shapovalov wrote:
> On 2015-07-05 at 16:06 +0200, Dušan Čolić wrote:
>> On 5 Jul 2015 15:12, "Ivan Shapovalov"<intelfx100@gmail.com>  wrote:
>>> On 2015-07-05 at 02:33 +0800, Edward Shishkin wrote:
>>>> On 07/05/2015 01:53 AM, Ivan Shapovalov wrote:
>>>>> On 2015-07-04 at 15:53 +0800, Edward Shishkin wrote:
>>>>>> [...]
>>>>>> 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
>>> Yeah, sure. So... new superblock format with two extra fields?
>>>
>> But what happens when someone makes an image of whole partition and
>> uses it
>> on new different ssd?
> Maybe we can make a tunefs.reiser4 (just) for that purpose.

--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]

On 2016-02-09 at 18:53 +0100, Edward Shishkin wrote:
> Hi all,
> 
> There is a pending patch for precise discarsd, which I can not merge
> because it is incomplete. Just want to know, is there any progress on
> this?
> 
> So we found that calculating discard params by mkfs and storing
> them in superblock is a dirty option, so I suggest to reserve a
> contiguous area (1 MiB?) on disk at "mkfs -d" time (just mark it busy
> in the bitmap). And calculate erase unit size and offset at mount
> time.
> If calculation failed for some reasons, then use non-precise discard.
> 
> So, I think, we'll need one d32 field in disk superblock, which
> indicates
> number of reserved blocks (0 means no reservation) and a pair of
> definitions in disk_format40.h:
> 
> #define FORMAT40_FIRST_RESERVED_FOR_PROBING \
>        ((REISER4_MASTER_OFFSET / PAGE_CACHE_SIZE) + 6)
> #define FORMAT40_MAX_BLOCKS_RESERVED_FOR_PROBING
> 
> If any questions, or technical stoppers, then let me know.
> 
> Thanks,
> Edward.
> 

Hello Edward,

yes, finishing this is on top of my to-do list (but it is being
dequeued at a very slow rate due to the university...).

I was under assumption of that we still want to go by path of probing
parameters at mkfs time + having a special utility for rewriting these
fields. But if you are now ok with probing at mount time, then that's
great. I'll try to do something in nearest week or two.

-- 
Ivan Shapovalov / intelfx /


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Edward Shishkin]

On 02/10/2016 05:04 AM, Ivan Shapovalov wrote:
> On 2016-02-09 at 18:53 +0100, Edward Shishkin wrote:
>> Hi all,
>>
>> There is a pending patch for precise discarsd, which I can not merge
>> because it is incomplete. Just want to know, is there any progress on
>> this?
>>
>> So we found that calculating discard params by mkfs and storing
>> them in superblock is a dirty option, so I suggest to reserve a
>> contiguous area (1 MiB?) on disk at "mkfs -d" time (just mark it busy
>> in the bitmap). And calculate erase unit size and offset at mount
>> time.
>> If calculation failed for some reasons, then use non-precise discard.
>>
>> So, I think, we'll need one d32 field in disk superblock, which
>> indicates
>> number of reserved blocks (0 means no reservation) and a pair of
>> definitions in disk_format40.h:
>>
>> #define FORMAT40_FIRST_RESERVED_FOR_PROBING \
>>         ((REISER4_MASTER_OFFSET / PAGE_CACHE_SIZE) + 6)
>> #define FORMAT40_MAX_BLOCKS_RESERVED_FOR_PROBING
>>
>> If any questions, or technical stoppers, then let me know.
>>
>> Thanks,
>> Edward.
>>
> Hello Edward,
>
> yes, finishing this is on top of my to-do list (but it is being
> dequeued at a very slow rate due to the university...).


Ah, this is of highest priority, ofc.


>
> I was under assumption of that we still want to go by path of probing
> parameters at mkfs time + having a special utility for rewriting these


I am afraid that 99% of users will be unaware of that utility..

Thanks,
Edward.


> fields. But if you are now ok with probing at mount time, then that's
> great. I'll try to do something in nearest week or two.
>

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

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 2739 bytes --]

On 2016-02-09 at 18:53 +0100, Edward Shishkin wrote:
> Hi all,
> 
> There is a pending patch for precise discarsd, which I can not merge
> because it is incomplete. Just want to know, is there any progress on
> this?
> 
> So we found that calculating discard params by mkfs and storing
> them in superblock is a dirty option, so I suggest to reserve a
> contiguous area (1 MiB?) on disk at "mkfs -d" time (just mark it busy
> in the bitmap). And calculate erase unit size and offset at mount
> time.
> If calculation failed for some reasons, then use non-precise discard.
> 
> So, I think, we'll need one d32 field in disk superblock, which
> indicates
> number of reserved blocks (0 means no reservation) and a pair of
> definitions in disk_format40.h:
> 
> #define FORMAT40_FIRST_RESERVED_FOR_PROBING \
>        ((REISER4_MASTER_OFFSET / PAGE_CACHE_SIZE) + 6)
> #define FORMAT40_MAX_BLOCKS_RESERVED_FOR_PROBING
> 
> If any questions, or technical stoppers, then let me know.
> 
> Thanks,
> Edward.

I guess it would be nicer to allocate the needed space dynamically at
mount time. However, there is a problem: where to put the probing code
in the fill_super() (I suppose?) sequence? We want the allocator to be
intact, but nothing should be written to the filesystem so far.

--
Ivan Shapovalov / intelfx /

> 
> 
> On 07/05/2015 05:13 PM, Ivan Shapovalov wrote:
> > 
> > On 2015-07-05 at 16:06 +0200, Dušan Čolić wrote:
> > > 
> > > On 5 Jul 2015 15:12, "Ivan Shapovalov"<intelfx100@gmail.com>  wro
> > > te:
> > > > 
> > > > On 2015-07-05 at 02:33 +0800, Edward Shishkin wrote:
> > > > > 
> > > > > On 07/05/2015 01:53 AM, Ivan Shapovalov wrote:
> > > > > > 
> > > > > > On 2015-07-04 at 15:53 +0800, Edward Shishkin wrote:
> > > > > > > 
> > > > > > > [...]
> > > > > > > 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
> > > > Yeah, sure. So... new superblock format with two extra fields?
> > > > 
> > > But what happens when someone makes an image of whole partition
> > > and
> > > uses it
> > > on new different ssd?
> > Maybe we can make a tunefs.reiser4 (just) for that purpose.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Edward Shishkin]

On 04/06/2016 06:54 PM, Ivan Shapovalov wrote:
> On 2016-02-09 at 18:53 +0100, Edward Shishkin wrote:
>> Hi all,
>>
>> There is a pending patch for precise discarsd, which I can not merge
>> because it is incomplete. Just want to know, is there any progress on
>> this?
>>
>> So we found that calculating discard params by mkfs and storing
>> them in superblock is a dirty option, so I suggest to reserve a
>> contiguous area (1 MiB?) on disk at "mkfs -d" time (just mark it busy
>> in the bitmap). And calculate erase unit size and offset at mount
>> time.
>> If calculation failed for some reasons, then use non-precise discard.
>>
>> So, I think, we'll need one d32 field in disk superblock, which
>> indicates
>> number of reserved blocks (0 means no reservation) and a pair of
>> definitions in disk_format40.h:
>>
>> #define FORMAT40_FIRST_RESERVED_FOR_PROBING \
>>         ((REISER4_MASTER_OFFSET / PAGE_CACHE_SIZE) + 6)
>> #define FORMAT40_MAX_BLOCKS_RESERVED_FOR_PROBING
>>
>> If any questions, or technical stoppers, then let me know.
>>
>> Thanks,
>> Edward.
> I guess it would be nicer to allocate the needed space dynamically at
> mount time.


And if no enough space, then switch to non-precise discard mode? OK.
Since the probing code is for SSD drives, it shouldn't lead to long mounts
in the case of big terabyte partitions, which are full of data.


>   However, there is a problem: where to put the probing code
> in the fill_super() (I suppose?) sequence?


Put it in try_init_format40(), right after the sa_init_allocator():
seems to be a right place.

Thanks,
Edward.


>   We want the allocator to be
> intact, but nothing should be written to the filesystem so far.
>
> --
> Ivan Shapovalov / intelfx /
>
>>
>> On 07/05/2015 05:13 PM, Ivan Shapovalov wrote:
>>> On 2015-07-05 at 16:06 +0200, Dušan Čolić wrote:
>>>> On 5 Jul 2015 15:12, "Ivan Shapovalov"<intelfx100@gmail.com>  wro
>>>> te:
>>>>> On 2015-07-05 at 02:33 +0800, Edward Shishkin wrote:
>>>>>> On 07/05/2015 01:53 AM, Ivan Shapovalov wrote:
>>>>>>> On 2015-07-04 at 15:53 +0800, Edward Shishkin wrote:
>>>>>>>> [...]
>>>>>>>> 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
>>>>> Yeah, sure. So... new superblock format with two extra fields?
>>>>>
>>>> But what happens when someone makes an image of whole partition
>>>> and
>>>> uses it
>>>> on new different ssd?
>>> Maybe we can make a tunefs.reiser4 (just) for that purpose.

--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html