Subject: + fat-permit-to-return-phy-block-number-by-fibmap-in-fallocated-region.patch added to -mm tree
To: namjae.jeon@xxxxxxxxxxx,a.sahrawat@xxxxxxxxxxx,hirofumi@xxxxxxxxxxxxxxxxxx
From: akpm@xxxxxxxxxxxxxxxxxxxx
Date: Thu, 10 Oct 2013 15:02:40 -0700
The patch titled
Subject: fat: permit to return phy block number by fibmap in fallocated region
has been added to the -mm tree. Its filename is
fat-permit-to-return-phy-block-number-by-fibmap-in-fallocated-region.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/fat-permit-to-return-phy-block-number-by-fibmap-in-fallocated-region.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/fat-permit-to-return-phy-block-number-by-fibmap-in-fallocated-region.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Namjae Jeon <namjae.jeon@xxxxxxxxxxx>
Subject: fat: permit to return phy block number by fibmap in fallocated region
Make the fibmap call the return the proper physical block number for any
offset request in the fallocated range.
Signed-off-by: Namjae Jeon <namjae.jeon@xxxxxxxxxxx>
Signed-off-by: Amit Sahrawat <a.sahrawat@xxxxxxxxxxx>
Cc: OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
fs/fat/cache.c | 16 ++++++++++++++--
fs/fat/inode.c | 4 ++--
2 files changed, 16 insertions(+), 4 deletions(-)
diff -puN fs/fat/cache.c~fat-permit-to-return-phy-block-number-by-fibmap-in-fallocated-region fs/fat/cache.c
--- a/fs/fat/cache.c~fat-permit-to-return-phy-block-number-by-fibmap-in-fallocated-region
+++ a/fs/fat/cache.c
@@ -312,6 +312,7 @@ int fat_bmap(struct inode *inode, sector
const unsigned char blocksize_bits = sb->s_blocksize_bits;
sector_t last_block;
int cluster, offset;
+ loff_t i_size = i_size_read(inode);
*phys = 0;
*mapped_blocks = 0;
@@ -323,10 +324,20 @@ int fat_bmap(struct inode *inode, sector
return 0;
}
- last_block = (i_size_read(inode) + (blocksize - 1)) >> blocksize_bits;
+ last_block = (i_size + (blocksize - 1)) >> blocksize_bits;
if (sector >= last_block) {
- if (!create)
+ if (!create) {
+ /*
+ * to map cluster in case of read request
+ * for a block in fallocated region
+ */
+ if (MSDOS_I(inode)->i_disksize >
+ round_up(i_size, sb->s_blocksize)) {
+ goto out_map_cluster;
+ }
+
return 0;
+ }
/*
* ->i_disksize can access on only allocation path.
@@ -339,6 +350,7 @@ int fat_bmap(struct inode *inode, sector
return 0;
}
+out_map_cluster:
cluster = sector >> (sbi->cluster_bits - sb->s_blocksize_bits);
offset = sector & (sbi->sec_per_clus - 1);
cluster = fat_bmap_cluster(inode, cluster);
diff -puN fs/fat/inode.c~fat-permit-to-return-phy-block-number-by-fibmap-in-fallocated-region fs/fat/inode.c
--- a/fs/fat/inode.c~fat-permit-to-return-phy-block-number-by-fibmap-in-fallocated-region
+++ a/fs/fat/inode.c
@@ -245,9 +245,9 @@ static sector_t _fat_bmap(struct address
sector_t blocknr;
/* fat_get_cluster() assumes the requested blocknr isn't truncated. */
- down_read(&MSDOS_I(mapping->host)->truncate_lock);
+ mutex_lock(&mapping->host->i_mutex);
blocknr = generic_block_bmap(mapping, block, fat_get_block);
- up_read(&MSDOS_I(mapping->host)->truncate_lock);
+ mutex_unlock(&mapping->host->i_mutex);
return blocknr;
}
_
Patches currently in -mm which might be from namjae.jeon@xxxxxxxxxxx are
fat-add-i_disksize-to-represent-uninitialized-size.patch
fat-add-fat_fallocate-operation.patch
fat-zero-out-seek-range-on-_fat_get_block.patch
fat-fallback-to-buffered-write-in-case-of-fallocatded-region-on-direct-io.patch
fat-permit-to-return-phy-block-number-by-fibmap-in-fallocated-region.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
