linux-ext4 - Re: Question on fallocate/ftruncate sequence (and flags)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4A68C9EC.4050301@redhat.com>
Date:	Thu, 23 Jul 2009 15:37:00 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	Frank Mayhar <fmayhar@...gle.com>
CC:	Andreas Dilger <adilger@....com>,
	Curt Wohlgemuth <curtw@...gle.com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: Question on fallocate/ftruncate sequence (and flags)

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?

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.

-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html