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]

Date:	Wed, 10 Sep 2008 10:11:02 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Theodore Tso <tytso@....EDU>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Mark Fasheh <mfasheh@...e.com>,
	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 10:07:19AM -0400, Theodore Tso wrote:
> As a suggestion, how about adding some __u32 and __u64 reserved
> fields, some of which are reserved for use by the filesystem (i.e.,
> you have to check f_type as returned by statfs to know what can be
> used), and some for future generic expansions to the generic FIEMAP
> interface.  When designing a userspace interfaces, leaving room in
> data structures for future expansion is a good thing, since it can
> avoid needing to have multiple versions of an interface when we need
> to expand the data structure.
> 
> While I can understand not wanting to have any new kernel functions
> without any mainline users for that interface, leaving a few reserved
> fields in data structures is just a smart thing to do, and has little
> or no downsides.

Leaving some spare space in the structure is fine with me, although I
doubt we'll ever use it for a scheme like that, more like other things.

> Interface minimalism to allow for flexibility later is one thing; but
> taken to extremes, it it's just stupid.  For example, if we didn't
> have any filesystems that needed 64-bit fields in mainline, would that
> be a justification for making data structures to use 32-bit fields and
> forcing a flag data interface change in the future.  Sometimes we can
> look ahead just a little bit and design interfaces which are foward
> compatible.  And it's pretty clear that btrfs will need something like
> fe_device, although whether it should be a 32-bit index or something
> else like a 128-bit UUID admittedly might not be clear at the moment.
> But leaving room in the data structure for future growth is just a
> intelligent thing to do.

No, if you look at btrfs or the not public bit for mirrored allocations
groups in XFS you'll notice that an extent can be happily on more than
once device.  So to support this we'd need a list of device plus a field
for the algorithm how to balance it over the devices.

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