[PATCH v3 1/6] fat: add i_disksize to represent uninitialized size

[PATCH v3 1/6] fat: add i_disksize to represent uninitialized size

[Namjae Jeon]

From: Namjae Jeon <namjae.jeon@samsung.com>

Add i_disksize to represent uninitialized allocated size.
And mmu_private represent initialized allocated size.

Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Amit Sahrawat <a.sahrawat@samsung.com>
---
 fs/fat/cache.c |    6 +++---
 fs/fat/fat.h   |    3 ++-
 fs/fat/file.c  |    4 +++-
 fs/fat/inode.c |    4 ++++
 4 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/fs/fat/cache.c b/fs/fat/cache.c
index 91ad9e1..a132666 100644
--- a/fs/fat/cache.c
+++ b/fs/fat/cache.c
@@ -329,10 +329,10 @@ int fat_bmap(struct inode *inode, sector_t sector, sector_t *phys,
 			return 0;
 
 		/*
-		 * ->mmu_private can access on only allocation path.
-		 * (caller must hold ->i_mutex)
+		 * Both ->mmu_private and ->i_disksize can access
+		 * on only allocation path. (caller must hold ->i_mutex)
 		 */
-		last_block = (MSDOS_I(inode)->mmu_private + (blocksize - 1))
+		last_block = (MSDOS_I(inode)->i_disksize + (blocksize - 1))
 			>> blocksize_bits;
 		if (sector >= last_block)
 			return 0;
diff --git a/fs/fat/fat.h b/fs/fat/fat.h
index 7c31f4b..7b5851f 100644
--- a/fs/fat/fat.h
+++ b/fs/fat/fat.h
@@ -118,7 +118,8 @@ struct msdos_inode_info {
 	unsigned int cache_valid_id;
 
 	/* NOTE: mmu_private is 64bits, so must hold ->i_mutex to access */
-	loff_t mmu_private;	/* physically allocated size */
+	loff_t mmu_private;	/* physically allocated size (initialized) */
+	loff_t i_disksize;	/* physically allocated size (uninitialized) */
 
 	int i_start;		/* first cluster or 0 */
 	int i_logstart;		/* logical first cluster */
diff --git a/fs/fat/file.c b/fs/fat/file.c
index 9b104f5..0bf0d28 100644
--- a/fs/fat/file.c
+++ b/fs/fat/file.c
@@ -300,8 +300,10 @@ void fat_truncate_blocks(struct inode *inode, loff_t offset)
 	 * This protects against truncating a file bigger than it was then
 	 * trying to write into the hole.
 	 */
-	if (MSDOS_I(inode)->mmu_private > offset)
+	if (MSDOS_I(inode)->i_disksize > offset) {
 		MSDOS_I(inode)->mmu_private = offset;
+		MSDOS_I(inode)->i_disksize = offset;
+	}
 
 	nr_clusters = (offset + (cluster_size - 1)) >> sbi->cluster_bits;
 
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 854b578..7e5531a 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -93,6 +93,7 @@ static inline int __fat_get_block(struct inode *inode, sector_t iblock,
 
 	*max_blocks = min(mapped_blocks, *max_blocks);
 	MSDOS_I(inode)->mmu_private += *max_blocks << sb->s_blocksize_bits;
+	MSDOS_I(inode)->i_disksize = MSDOS_I(inode)->mmu_private;
 
 	err = fat_bmap(inode, iblock, &phys, &mapped_blocks, create);
 	if (err)
@@ -408,6 +409,7 @@ int fat_fill_inode(struct inode *inode, struct msdos_dir_entry *de)
 		if (error < 0)
 			return error;
 		MSDOS_I(inode)->mmu_private = inode->i_size;
+		MSDOS_I(inode)->i_disksize = inode->i_size;
 
 		set_nlink(inode, fat_subdirs(inode));
 	} else { /* not a directory */
@@ -423,6 +425,7 @@ int fat_fill_inode(struct inode *inode, struct msdos_dir_entry *de)
 		inode->i_fop = &fat_file_operations;
 		inode->i_mapping->a_ops = &fat_aops;
 		MSDOS_I(inode)->mmu_private = inode->i_size;
+		MSDOS_I(inode)->i_disksize = inode->i_size;
 	}
 	if (de->attr & ATTR_SYS) {
 		if (sbi->options.sys_immutable)
@@ -1223,6 +1226,7 @@ static int fat_read_root(struct inode *inode)
 			   & ~((loff_t)sbi->cluster_size - 1)) >> 9;
 	MSDOS_I(inode)->i_logstart = 0;
 	MSDOS_I(inode)->mmu_private = inode->i_size;
+	MSDOS_I(inode)->i_disksize = inode->i_size;
 
 	fat_save_attrs(inode, ATTR_DIR);
 	inode->i_mtime.tv_sec = inode->i_atime.tv_sec = inode->i_ctime.tv_sec = 0;
-- 
1.7.9.5

Re: [PATCH v3 1/6] fat: add i_disksize to represent uninitialized size

[OGAWA Hirofumi]

Namjae Jeon <linkinjeon@gmail.com> writes:

> From: Namjae Jeon <namjae.jeon@samsung.com>
>
> Add i_disksize to represent uninitialized allocated size.
> And mmu_private represent initialized allocated size.

Don't we need to update ->i_disksize after cont_write_begin()?
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [PATCH v3 1/6] fat: add i_disksize to represent uninitialized size

[Namjae Jeon]

2014-02-03, OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>:
> Namjae Jeon <linkinjeon@gmail.com> writes:
>
>> From: Namjae Jeon <namjae.jeon@samsung.com>
>>
>> Add i_disksize to represent uninitialized allocated size.
>> And mmu_private represent initialized allocated size.
>
> Don't we need to update ->i_disksize after cont_write_begin()?
We don't need to update i_disksize after cont_write_begin.
It is taken care by the fat_get_block after the allocation.
For all write paths we align the mmu_private and i_disksize from
fat_fill_inode and fat_get_block.

Thanks.
> --
> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
>

Re: [PATCH v3 1/6] fat: add i_disksize to represent uninitialized size

[OGAWA Hirofumi]

Namjae Jeon <linkinjeon@gmail.com> writes:

> 2014-02-03, OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>:
>> Namjae Jeon <linkinjeon@gmail.com> writes:
>>
>>> From: Namjae Jeon <namjae.jeon@samsung.com>
>>>
>>> Add i_disksize to represent uninitialized allocated size.
>>> And mmu_private represent initialized allocated size.
>>
>> Don't we need to update ->i_disksize after cont_write_begin()?
> We don't need to update i_disksize after cont_write_begin.
> It is taken care by the fat_get_block after the allocation.
> For all write paths we align the mmu_private and i_disksize from
> fat_fill_inode and fat_get_block.

fat_fill_inode() just set i_disksize to i_size. So, it is not aligned by
cluster size or block size.

E.g. ->mmu_private = 500. Then, cont_write_begin() can set ->mmu_private
to 512 on some case. In this case, fat_get_block() will not be called,
because no new allocation.

If this is true, it would be possible to have ->mmu_private == 512 and
->i_disksize == 500. 

I'm missing something?

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [PATCH v3 1/6] fat: add i_disksize to represent uninitialized size

[OGAWA Hirofumi]

OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:

>>> Don't we need to update ->i_disksize after cont_write_begin()?
>> We don't need to update i_disksize after cont_write_begin.
>> It is taken care by the fat_get_block after the allocation.
>> For all write paths we align the mmu_private and i_disksize from
>> fat_fill_inode and fat_get_block.
>
> fat_fill_inode() just set i_disksize to i_size. So, it is not aligned by
> cluster size or block size.
>
> E.g. ->mmu_private = 500. Then, cont_write_begin() can set ->mmu_private
> to 512 on some case. In this case, fat_get_block() will not be called,
> because no new allocation.
>
> If this is true, it would be possible to have ->mmu_private == 512 and
> ->i_disksize == 500. 
>
> I'm missing something?

BTW, even if above was right, I'm not checking whether updating
->i_disksize after cont_write_begin() is right fix or not.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [PATCH v3 1/6] fat: add i_disksize to represent uninitialized size

[Namjae Jeon]

2014-02-04, OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>:
> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:
>
>>>> Don't we need to update ->i_disksize after cont_write_begin()?
>>> We don't need to update i_disksize after cont_write_begin.
>>> It is taken care by the fat_get_block after the allocation.
>>> For all write paths we align the mmu_private and i_disksize from
>>> fat_fill_inode and fat_get_block.
>>
>> fat_fill_inode() just set i_disksize to i_size. So, it is not aligned by
>> cluster size or block size.
>>
>> E.g. ->mmu_private = 500. Then, cont_write_begin() can set ->mmu_private
>> to 512 on some case. In this case, fat_get_block() will not be called,
>> because no new allocation.
>>
>> If this is true, it would be possible to have ->mmu_private == 512 and
>> ->i_disksize == 500.
>>
>> I'm missing something?
>
> BTW, even if above was right, I'm not checking whether updating
> ->i_disksize after cont_write_begin() is right fix or not.
I understand your concern. these can be mismatched.
But, when checking your doubt, I can not find any side effect.
I think that there is no issue regardless of alignment of two value,
in the cont_write_begin.
Could you please share any point I am missing ?
If you suggest checking point or test method, I can check more and
share the result.

Thanks OGAWA.
> --
> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
>

Re: [PATCH v3 1/6] fat: add i_disksize to represent uninitialized size

[OGAWA Hirofumi]

Namjae Jeon <linkinjeon@gmail.com> writes:

>>> fat_fill_inode() just set i_disksize to i_size. So, it is not aligned by
>>> cluster size or block size.
>>>
>>> E.g. ->mmu_private = 500. Then, cont_write_begin() can set ->mmu_private
>>> to 512 on some case. In this case, fat_get_block() will not be called,
>>> because no new allocation.
>>>
>>> If this is true, it would be possible to have ->mmu_private == 512 and
>>> ->i_disksize == 500.
>>>
>>> I'm missing something?
>>
>> BTW, even if above was right, I'm not checking whether updating
>> ->i_disksize after cont_write_begin() is right fix or not.
> I understand your concern. these can be mismatched.  But, when
> checking your doubt, I can not find any side effect.  I think that
> there is no issue regardless of alignment of two value, in the
> cont_write_begin.  Could you please share any point I am missing ?  If
> you suggest checking point or test method, I can check more and share
> the result.

I'm not checking whether it is wrong or not. But, like you said,
->mmu_private > ->i_disksize is wrong in theory.

Although, it might have no real problem.

So, how about to set ->i_disksize to aligned by blocksize at first
(i.e. when initializing the inode)?

This may change the behavior when ->mmu_private is not aligned to
blocksize in current patchset. But, in theory, it is right state
(between ->mmu_private and ->i_disksize is uninitialized). I guess, we
can do it with small adjustments, and keep state valid in theory too.

This is just a my guess, so it might be wrong though. I guess, worth to
try to consider.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [PATCH v3 1/6] fat: add i_disksize to represent uninitialized size

[Namjae Jeon]

2014-02-06, OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>:
> Namjae Jeon <linkinjeon@gmail.com> writes:
>
>>>> fat_fill_inode() just set i_disksize to i_size. So, it is not aligned
>>>> by
>>>> cluster size or block size.
>>>>
>>>> E.g. ->mmu_private = 500. Then, cont_write_begin() can set
>>>> ->mmu_private
>>>> to 512 on some case. In this case, fat_get_block() will not be called,
>>>> because no new allocation.
>>>>
>>>> If this is true, it would be possible to have ->mmu_private == 512 and
>>>> ->i_disksize == 500.
>>>>
>>>> I'm missing something?
>>>
>>> BTW, even if above was right, I'm not checking whether updating
>>> ->i_disksize after cont_write_begin() is right fix or not.
>> I understand your concern. these can be mismatched.  But, when
>> checking your doubt, I can not find any side effect.  I think that
>> there is no issue regardless of alignment of two value, in the
>> cont_write_begin.  Could you please share any point I am missing ?  If
>> you suggest checking point or test method, I can check more and share
>> the result.
>
> I'm not checking whether it is wrong or not. But, like you said,
> ->mmu_private > ->i_disksize is wrong in theory.
>
> Although, it might have no real problem.
>
> So, how about to set ->i_disksize to aligned by blocksize at first
> (i.e. when initializing the inode)?
Yes, It is good idea.
>
> This may change the behavior when ->mmu_private is not aligned to
> blocksize in current patchset. But, in theory, it is right state
> (between ->mmu_private and ->i_disksize is uninitialized). I guess, we
> can do it with small adjustments, and keep state valid in theory too.
Right.
>
> This is just a my guess, so it might be wrong though. I guess, worth to
> try to consider.
Okay, I will include it in next patch-set after checking.

Thanks for your review!
>
> Thanks.
> --
> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
>