linux-ext4 - Re: [PATCH 0/3] Fiemap, an extent mapping ioctl

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: <20080910161037.GH4563@wotan.suse.de>
Date:	Wed, 10 Sep 2008 09:10:37 -0700
From:	Mark Fasheh <mfasheh@...e.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Andreas Dilger <adilger@....com>,
	Eric Sandeen <esandeen@...hat.com>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 0/3] Fiemap, an extent mapping ioctl

On Wed, Sep 10, 2008 at 09:47:27AM -0400, Christoph Hellwig wrote:
> On Wed, Sep 10, 2008 at 05:49:34AM -0700, Mark Fasheh wrote:
> > * FIEMAP_FLAG_XATTR
> > If this flag is set, the extents returned will describe the inodes
> > extended attribute lookup tree, instead of it's data tree.
> 
> So does this actually make sense for any filesystem but XFS?  Still
> seems like a not too useful option for a highlevel generic interface.
> 
> > 	__u32	fe_device;   /* device number for extent */
> 
> As sayd before please kill thise one.  It doesn't make any sense at all
> for any merged or near mainline FS.  It'd be an utterly stupid
> lustre-specific hack that still doesn't make much sense.
> 
> > * FIEMAP_EXTENT_NO_BYPASS
> > Direct access to the data in this extent is illegal or will have
> > undefined results.
> 
> Huh?  What is direct access?  Direct access as in bypassing the
> filesystem and writing to the blockdev directly always has undefined
> results.
> 
> > * FIEMAP_EXTENT_SECONDARY
> > The data for this extent is in secondary storage (e.g. HSM).  If the
> > data is not also in the filesystem, then FIEMAP_EXTENT_NO_BYPASS
> > should also be set.
> 
> No HSM in mainline, so please drop it.  We can add it once we get HSM
> support.
> 
> > * FIEMAP_EXTENT_NET
> >   - This will also set FIEMAP_EXTENT_NO_BYPASS
> > The data for this extent is not stored in a locally-accessible device.
> 
> Doesn't make any sense currently, please drop.
> 
> > * FIEMAP_EXTENT_DATA_COMPRESSED
> >   - This will also set FIEMAP_EXTENT_NO_BYPASS
> > The data in this extent has been compressed by the file system.
> 
> Add once we have users for it.

Ok, aside from NO_BYPASS all your proposed changes have been made. Not sure
about NO_BYPASS. Maybe we just update the description? In the meantime, can
we please just put this in -mm? I'll happily do a patch on top of it all to
rename EXTENT_NO_BYPASS once we agree on a name.

Please pull
git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2.git fiemap
	--Mark

--
Mark Fasheh
--
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