From: Mingming Cao <cmm@us.ibm.com>
To: linux-ext4@vger.kernel.org
Subject: [PATCH] ext4: delayed allocation i_blocks fix for stat(2)
Date: Mon, 07 Jul 2008 16:36:39 -0700 [thread overview]
Message-ID: <1215473799.6702.9.camel@mingming-laptop> (raw)
ext4: delayed allocation i_blocks fix for stat(2)
From: Mingming Cao <cmm@us.ibm.com>
Right now i_blocks is not getting updated until the disks are actually
allocaed on disk. This means with delayed allocation, right after files
are copied, "ls -sF" shoes the file as taking 0 blocks on disk. "du"
also shows the files taking zero space, which is highly confusing to the user.
Since current delayed allocation already keep track of per-inode total number
of blocks that are subject to delayed allocation, this patch fix this by using
that to adjust the value returned by stat(2). When real block allocation
is done, the i_blocks will get updated. Since the reserved blocks for delayed
allocation will be decreased, this will be keep value returned by stat(2)
consistent.
Signed-off-by: Mingming Cao <cmm@us.ibm.com>
---
fs/ext4/ext4.h | 2 ++
fs/ext4/file.c | 1 +
fs/ext4/inode.c | 26 ++++++++++++++++++++++++++
3 files changed, 29 insertions(+)
Index: linux-2.6.26-rc9/fs/ext4/ext4.h
===================================================================
--- linux-2.6.26-rc9.orig/fs/ext4/ext4.h 2008-07-07 16:29:23.000000000 -0700
+++ linux-2.6.26-rc9/fs/ext4/ext4.h 2008-07-07 16:32:54.000000000 -0700
@@ -1059,6 +1059,8 @@ int ext4_get_blocks_handle(handle_t *han
extern struct inode *ext4_iget(struct super_block *, unsigned long);
extern int ext4_write_inode (struct inode *, int);
extern int ext4_setattr (struct dentry *, struct iattr *);
+extern int ext4_getattr(struct vfsmount *mnt, struct dentry *dentry,
+ struct kstat *stat);
extern void ext4_delete_inode (struct inode *);
extern int ext4_sync_inode (handle_t *, struct inode *);
extern void ext4_discard_reservation (struct inode *);
Index: linux-2.6.26-rc9/fs/ext4/file.c
===================================================================
--- linux-2.6.26-rc9.orig/fs/ext4/file.c 2008-07-07 16:29:21.000000000 -0700
+++ linux-2.6.26-rc9/fs/ext4/file.c 2008-07-07 16:29:51.000000000 -0700
@@ -161,6 +161,7 @@ const struct file_operations ext4_file_o
const struct inode_operations ext4_file_inode_operations = {
.truncate = ext4_truncate,
.setattr = ext4_setattr,
+ .getattr = ext4_getattr,
#ifdef CONFIG_EXT4DEV_FS_XATTR
.setxattr = generic_setxattr,
.getxattr = generic_getxattr,
Index: linux-2.6.26-rc9/fs/ext4/inode.c
===================================================================
--- linux-2.6.26-rc9.orig/fs/ext4/inode.c 2008-07-07 16:29:22.000000000 -0700
+++ linux-2.6.26-rc9/fs/ext4/inode.c 2008-07-07 16:31:13.000000000 -0700
@@ -4203,6 +4203,32 @@ err_out:
return error;
}
+int ext4_getattr(struct vfsmount *mnt, struct dentry *dentry,
+ struct kstat *stat)
+{
+ struct inode *inode;
+ unsigned long delalloc_blocks;
+
+ inode = dentry->d_inode;
+ generic_fillattr(inode, stat);
+
+ /*
+ * We can't update i_blocks if the block allocation is delayed
+ * otherwise in the case of system crash before the real block
+ * allocation is done, we will have i_blocks inconsistent with
+ * on-disk file blocks.
+ * We always keep i_blocks updated together with real
+ * allocation. But to not confuse with user, stat
+ * will return the blocks that include the delayed allocation
+ * blocks for this file.
+ */
+ spin_lock(&EXT4_I(inode)->i_block_reservation_lock);
+ delalloc_blocks = EXT4_I(inode)->i_reserved_data_blocks;
+ spin_unlock(&EXT4_I(inode)->i_block_reservation_lock);
+
+ stat->blocks += (delalloc_blocks << inode->i_sb->s_blocksize_bits)>>9;
+ return 0;
+}
/*
* How many blocks doth make a writepage()?
next reply other threads:[~2008-07-07 23:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-07 23:36 Mingming Cao [this message]
2008-07-07 23:47 ` [PATCH] ext4: delayed allocation i_blocks fix for stat(2) Theodore Tso
2008-07-08 1:11 ` Eric Sandeen
2008-07-08 12:15 ` Peter Staubach
2008-07-08 20:02 ` Jan Kara
2008-07-08 22:55 ` Mingming Cao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1215473799.6702.9.camel@mingming-laptop \
--to=cmm@us.ibm.com \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox