From: Nicholas Miell <nmiell@comcast.net>
To: "Jörn Engel" <joern@logfs.org>
Cc: Andreas Dilger <adilger@sun.com>, Josef Bacik <jbacik@redhat.com>,
linux-fsdevel@vger.kernel.org,
Andreas Dilger <adilger@clusterfs.com>
Subject: Re: [RFC][PATCH] Implement SEEK_HOLE/SEEK_DATA
Date: Wed, 28 Nov 2007 16:06:25 -0800 [thread overview]
Message-ID: <1196294785.18231.31.camel@entropy> (raw)
In-Reply-To: <20071128234842.GA8664@lazybastard.org>
On Thu, 2007-11-29 at 00:48 +0100, Jörn Engel wrote:
> On Wed, 28 November 2007 16:39:59 -0700, Andreas Dilger wrote:
> > On Nov 28, 2007 14:56 -0800, Nicholas Miell wrote:
> > >
> > > type: one of EXTENT_TYPE_HOLE, EXTENT_TYPE_DATA, EXTENT_TYPE_EXTENTS,
> > > EXTENT_TYPE_COMPRESSED, EXTENT_TYPE_UNCOMPRESSED etc.
> >
> > This is what FIEMAP is supposed to do. We wrote a spec and implemented
> > a prototype for ext4, but haven't had time to make it generic to move
> > the large part of the code into the VFS. If someone wanted to take that
> > up, it would be much appreciated.
> >
> > See "[RFC] add FIEMAP ioctl to efficiently map file allocation" in
> > linux-fsdevel for details on this interface.
>
> I didn't follow the discussion much, since it didn't appear to suit
> logfs too well. In a nutshell, logfs is purely block-based, prepends
> every block with a header, may compress blocks and packs them as tightly
> as possible (byte alignment).
>
> Maybe the "MAP" part fooled me to believe FIEMAP would also expose
> physical location of extends on the medium. But reading the proposal
> again, I am unsure about that part. If physical locations are exposed,
> SEEK_HOLE/SEEK_DATA is significantly more elegant for logfs. If not,
> FIEMAP could be useful.
>
> Jörn
>
I'd have to reread the original proposal, but I remember FIEMAP as being
a generalized way of getting information about a files extents. I think
the original proposal only dealt with mapping file offsets to physical
extents, but IIRC the interface was flexible enough to implement a
"where are the holes" request.
Regardless, SEEK_HOLE/SEEK_DATA being a better suited interface for the
needs of logfs doesn't make it the best interface for that need.
--
Nicholas Miell <nmiell@comcast.net>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2007-11-29 0:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-28 20:02 [RFC][PATCH] Implement SEEK_HOLE/SEEK_DATA Josef Bacik
2007-11-28 21:56 ` Brad Boyer
2007-11-28 23:38 ` Josef Bacik
2007-11-28 22:56 ` Nicholas Miell
2007-11-28 23:33 ` Josef Bacik
2007-11-28 23:50 ` Nicholas Miell
2007-11-28 23:39 ` Andreas Dilger
2007-11-28 23:48 ` Jörn Engel
2007-11-29 0:06 ` Nicholas Miell [this message]
2007-11-29 3:07 ` Jörn Engel
2007-11-29 3:27 ` Andreas Dilger
2007-11-29 4:14 ` Jörn Engel
2007-11-28 23:49 ` Andreas Dilger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1196294785.18231.31.camel@entropy \
--to=nmiell@comcast.net \
--cc=adilger@clusterfs.com \
--cc=adilger@sun.com \
--cc=jbacik@redhat.com \
--cc=joern@logfs.org \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.