[Top] [All Lists]

Re: [PATCH 2/4 v3] fiemap: add EXTENT_DATA_COMPRESSED flag

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 2/4 v3] fiemap: add EXTENT_DATA_COMPRESSED flag
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Fri, 13 Dec 2013 03:06:08 -0800
Cc: David Sterba <dsterba@xxxxxxx>, linux-fsdevel@xxxxxxxxxxxxxxx, adilger@xxxxxxxxx, linux-nilfs@xxxxxxxxxxxxxxx, mfasheh@xxxxxxxx, xfs@xxxxxxxxxxx, hch@xxxxxxxxxxxxx, linux-btrfs@xxxxxxxxxxxxxxx, viro@xxxxxxxxxxxxxxxxxx, linux-ext4@xxxxxxxxxxxxxxx, ocfs2-devel@xxxxxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20131212232443.GL31386@dastard>
References: <cover.1386778302.git.dsterba@xxxxxxx> <4f8d5dc5b51a43efaf16c39398c23a6276e40a30.1386778303.git.dsterba@xxxxxxx> <20131212232443.GL31386@dastard>
User-agent: Mutt/1.5.21 (2010-09-15)
On Fri, Dec 13, 2013 at 10:24:43AM +1100, Dave Chinner wrote:
> I'd prefer to just see the new physical length field always filled
> out, regardless of whether it is a compressed extent or not. In
> terms of backwards compatibility to userspace, it makes no
> difference because the value of reserved/unused fields is undefined
> by the API. Yes, the implementation zeros them, but there's nothing
> in the documentation that says "reserved fields must be zero".
> Hence I think we should just set it for every extent.
> >From the point of view of the kernel API (fiemap_fill_next_extent),
> passing the physical extent size in the "len" parameter for normal
> extents, then passing 0 for the "physical length" makes absolutely
> no sense.

I tend to agree, but the additional complication here is that this is
a change to an existing API.  We'd need another HAVE_PHYS_LEN flag for
non-compressed extents so that userspace can rely on it.  Given that
it's only useful for that case I think the userspace API introduced
is the best we can get.

I think however that we should always pass the phys_len argument in the
kernel API just to make it less confusing.

<Prev in Thread] Current Thread [Next in Thread>