Peter Staubach a écrit :
Few month ago, I ran a FFSB test on a 2.6.23 kernel enabling or not
the i_version flag.
http://bullopensource.org/ext4/20071116/ffsb-write.html
This is good information.
A couple of questions -- what is the "-I 256" option used for the ext4
mkfs?
This option force
hi,
Peter Staubach a écrit :
Is the perceived performance hit really going to be as large
as suspected? We already update the time fields fairly often
and we don't pay a huge penalty for those, or at least not a
penalty that we aren't willing to pay. Has anyone measured
the cost?
Few month
:12:37.0 +0200
+++ linux-2.6.22-rc2-ext4-1/fs/ext4/xattr.h 2007-05-25 17:12:41.0 +0200
@@ -74,6 +74,9 @@
extern void ext4_xattr_delete_inode(handle_t *, struct inode *);
extern void ext4_xattr_put_super(struct super_block *);
+int ext4_expand_extra_isize(struct inode *inode, int new
rmay return the object's
time_metadata attribute for this attribute's value but
only if the filesystem object can not be updated more
frequently than the resolution of time_metadata."
Signed-off-by: Jean Noel Cordenner <[EMAIL PRO
Hi,
This is an update of the i_version patch.
The i_version field is a 64bit counter that is set on every inode
creation and that is incremented every time the inode data is modified
(similarly to the "ctime" time-stamp).
The aim is to fulfill a NFSv4 requirement for rfc3530:
"5.5. Mandatory Att
