On Jul 23, 2009 15:37 -0500, Eric Sandeen wrote: > Frank Mayhar wrote: > > On Tue, 2009-07-21 at 15:54 -0600, Andreas Dilger wrote: > >> That said, we might need to have some kind of flag in the on-disk > >> inode to indicate that it was preallocated beyond EOF. Otherwise, > >> e2fsck will try and extend the file size to match the block count, > >> which isn't correct. We could also use this flag to determine if > >> truncate needs to be run on the inode even if the new size is the > >> same. > > > > As it happens there's already a flag, FS_FALLOC_FL, set by ext2 in > > fallocate(). Unfortunately ext4 is using that bit (0x00040000) for > > EXT4_HUGE_FILE_FL. (Ext4 is using another bit as well, 0x00100000, for > > EXT4_EXT_MIGRATE_FL when fs.h defines it as FS_DIRECTIO_FL.) I really > > want to use the FS_FALLOC_FL bit for this purpose but that means > > reallocating HUGE_FILE_FL to some other big. Objections? > > I'm confused (again?) :). I don't see FS_FALLOC_FL in the latest kernel > source, and ext2 (well, my ext2 anyway) can't do fallocate(). Google > (well, my google search) can't find it either. Is this something in > your tree? I think I recall Google working on a patch for fallocate on ext2, but it was vetoed from upstream inclusion because we don't want to flog a dead horse. Hence the Google patch to run ext4 w/o a journal. > As for: > > #define EXT4_EXT_MIGRATE 0x00100000 /* Inode is migrating */ > > this is not in the mask that FS_IOC_GETFLAGS can see ... and I don't > think anyone else uses FS_DIRECTIO_FL. > > I'm not sure if the flags not in FS_FL_USER_VISIBLE are supposed to be > fs-unique. Well, they are stored on disk, so we shouldn't have conflicts between ext2 and ext4 for sure. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
