linux-ext4 - Re: [PATCH 1/4] vfs: vfs-level fiemap interface

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:	Tue, 16 Sep 2008 17:31:07 -0400
From:	Theodore Tso <tytso@....edu>
To:	Mark Fasheh <mfasheh@...e.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Anton Altaparmakov <aia21@....ac.uk>,
	linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
	akpm@...uxfoundation.org
Subject: Re: [PATCH 1/4] vfs: vfs-level fiemap interface

On Mon, Sep 15, 2008 at 10:53:05AM -0700, Mark Fasheh wrote:
> On Mon, Sep 15, 2008 at 10:49:48AM -0400, Christoph Hellwig wrote:
> > I agree to you (or someone elses - don't remember anymore) suggestion
> > to put in more padding so we can add fields later.  I strongly disagree
> > putting in features now that we neither have a user, nor a usecase or
> > testcase for.
> 
> So, how about another 64 bits of padding in struct fiemap_extent? That could
> help cover future uses like compression, which might require another 64 bit
> offset field - we only have 32 bits of reserved space there right now.

What I'd recommend is a 56 byte structure:

struct fiemap_extent {
      __u64 fe_logical;  /* logical offset in bytes for the start of
                          * the extent from the beginning of the file */
      __u64 fe_physical; /* physical offset in bytes for the start
                          * of the extent from the beginning of the disk */
      __u64 fe_length;   /* length in bytes for this extent */
      __u64 fe_reserved64[2];
                                   * encoded/compressed on disk */
      __u32 fe_flags;    /* FIEMAP_EXTENT_* flags for this extent */
      __u32 fe_reserved[3];
};

Yeah, it's a little extra memory per extent, but filesystems seem to
always invent new things, and it seem spretty clear that we have at
least two extensions on deck (compression, multiple storage devices)
both of which have at least one implementation that are either in the
kernel or will likely enter the kernel.  So it's likely that there is
something that we may have missed, and leaving a little extra space
doesn't actually cost us that much.

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