| 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
| ||
|
Message-ID: <20070712072813.GA31260@in.ibm.com> Date: Thu, 12 Jul 2007 12:58:13 +0530 From: Suparna Bhattacharya <suparna@...ibm.com> To: Christoph Hellwig <hch@...radead.org>, "Amit K. Arora" <aarora@...ux.vnet.ibm.com>, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, linux-ext4@...r.kernel.org, adilger@...sterfs.com, David Chinner <dgc@....com>, cmm@...ibm.com, xfs@....sgi.com Subject: Re: [PATCH 4/7][TAKE5] support new modes in fallocate On Wed, Jul 11, 2007 at 10:03:12AM +0100, Christoph Hellwig wrote: > On Tue, Jul 03, 2007 at 05:16:50PM +0530, Amit K. Arora wrote: > > Well, if you see the modes proposed using above flags : > > > > #define FA_ALLOCATE 0 > > #define FA_DEALLOCATE FA_FL_DEALLOC > > #define FA_RESV_SPACE FA_FL_KEEP_SIZE > > #define FA_UNRESV_SPACE (FA_FL_DEALLOC | FA_FL_KEEP_SIZE | FA_FL_DEL_DATA) > > > > FA_FL_DEL_DATA is _not_ being used for preallocation. We have two modes > > for preallocation FA_ALLOCATE and FA_RESV_SPACE, which do not use this > > flag. Hence prealloction will never delete data. > > This mode is required only for FA_UNRESV_SPACE, which is a deallocation > > mode, to support any existing XFS aware applications/usage-scenarios. > > Sorry, but this doesn't make any sense. There is no need to put every > feature in the XFS ioctls in the syscalls. The XFS ioctls will need to > be supported forever anyway - as I suggested before they really should > be moved to generic code. > > What needs to be supported is what makes sense as an interface. > A punch a hole interface does make sense, but trying to hack this into > a preallocation system call is just madness. We're not IRIX or windows > that fit things into random subcall just because there was some space > left to squeeze them in. > > > > > > FA_FL_NO_MTIME 0x10 /* keep same mtime (default change on size, data change) */ > > > > > FA_FL_NO_CTIME 0x20 /* keep same ctime (default change on size, data change) */ > > > > > > NACK to these aswell. If i_size changes c/mtime need updates, if the size > > > doesn't chamge they don't. No need to add more flags for this. > > > > This requirement was from the point of view of HSM applications. Hope > > you saw Andreas previous post and are keeping that in mind. > > HSMs needs this basically for every system call, which screams for an > open flag like O_INVISIBLE anyway. Adding this in a generic way is > a good idea, but hacking bits and pieces that won't fit into the global > design is completely wrong. Why don't we just merge the interface for preallocation (essentially enough to satisfy posix_fallocate() and the simple XFS requirement for space reservation without changing file size), which there is clear agreement on (I hope :)). After all, this was all that we set out to do when we started. And leave all the dealloc/punch/hsm type features for separate future patches/ debates, those really shouldn't hold up the basic fallocate interface. I agree with Christoph that we are just diverging too much in trying to club those decisions here. Dave, Andreas, Ted ? Regards Suparna > - > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@...r.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Suparna Bhattacharya (suparna@...ibm.com) Linux Technology Center IBM Software Lab, India - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists