From: Josef Bacik <josef@redhat.com>
To: linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org, hch@infradead.org
Subject: [PATCH 1/2] fs: add SEEK_HOLE and SEEK_DATA flags
Date: Thu, 21 Apr 2011 15:42:33 -0400 [thread overview]
Message-ID: <1303414954-3315-1-git-send-email-josef@redhat.com> (raw)
This just gets us ready to support the SEEK_HOLE and SEEK_DATA flags. Turns out
using fiemap in things like cp cause more problems than it solves, so lets try
and give userspace an interface that doesn't suck. So we have
-SEEK_HOLE: this moves the file pos to the nearest hole in the file from the
given position. If the given position is a hole then pos won't move. A "hole"
is defined by whatever the fs feels like defining it to be. In simple things
like ext2/3 it will simplly mean an unallocated space in the file. For more
complex things where you have preallocated space then that is left up to the
filesystem. Since preallocated space is supposed to return all 0's it is
perfectly legitimate to have SEEK_HOLE dump you out at the start of a
preallocated extent, but then again if this is not something you can do and be
sure the extent isn't in the middle of being converted to a real extent then it
is also perfectly legitimate to skip preallocated extents and only park f_pos at
a truly unallocated section.
-SEEK_DATA: this is obviously a little more self-explanatory. Again the only
ambiguity comes in with preallocated extents. If you have an fs that can't
reliably tell that the preallocated extent is in the process of turning into a
real extent, it is correct for SEEK_DATA to park you at a preallocated extent.
Thanks,
Signed-off-by: Josef Bacik <josef@redhat.com>
---
fs/read_write.c | 3 +++
include/linux/fs.h | 4 +++-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/fs/read_write.c b/fs/read_write.c
index 5520f8a..5446d61 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -64,6 +64,9 @@ generic_file_llseek_unlocked(struct file *file, loff_t offset, int origin)
return file->f_pos;
offset += file->f_pos;
break;
+ case SEEK_DATA:
+ case SEEK_HOLE:
+ return -EINVAL;
}
if (offset < 0 && !unsigned_offsets(file))
diff --git a/include/linux/fs.h b/include/linux/fs.h
index dbd860a..1b72e0c 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -31,7 +31,9 @@
#define SEEK_SET 0 /* seek relative to beginning of file */
#define SEEK_CUR 1 /* seek relative to current file position */
#define SEEK_END 2 /* seek relative to end of file */
-#define SEEK_MAX SEEK_END
+#define SEEK_HOLE 3 /* seek to the closest hole */
+#define SEEK_DATA 4 /* seek to the closest data */
+#define SEEK_MAX SEEK_DATA
struct fstrim_range {
__u64 start;
--
1.7.2.3
next reply other threads:[~2011-04-21 19:42 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-21 19:42 Josef Bacik [this message]
2011-04-21 19:42 ` [PATCH 2/2] Btrfs: implement our own ->llseek Josef Bacik
2011-04-21 20:45 ` [PATCH 1/2] fs: add SEEK_HOLE and SEEK_DATA flags Theodore Tso
2011-04-21 21:29 ` Sunil Mushran
2011-04-22 3:23 ` Matthew Wilcox
2011-04-22 4:47 ` Christoph Hellwig
[not found] ` <loom.20110422T001650-760@post.gmane.org>
[not found] ` <BANLkTiknb+hzFAjpwESwMcqMVtkFc0HFQQ@mail.gmail.com>
2011-04-22 4:50 ` Christoph Hellwig
2011-04-22 11:28 ` Markus Trippelsdorf
2011-04-22 11:50 ` Eric Blake
2011-04-22 16:28 ` Sunil Mushran
2011-04-22 16:40 ` Eric Blake
2011-04-22 16:57 ` Sunil Mushran
2011-04-22 17:03 ` Eric Blake
2011-04-22 17:08 ` Sunil Mushran
2011-04-22 18:06 ` Andreas Dilger
2011-04-22 23:33 ` Sunil Mushran
2011-04-24 17:49 ` Jamie Lokier
2011-04-25 12:37 ` Eric Blake
2011-04-25 14:15 ` Jamie Lokier
[not found] ` <20110422112852.GB1627-tLCgZGx+iJ+kxVt8IV0GqQ@public.gmane.org>
2011-04-22 13:06 ` Eric Blake
2011-04-25 15:02 ` Nick Bowler
[not found] ` <20110425150227.GA10653-7BP4RkwGw0uXmMXjJBpWqg@public.gmane.org>
2011-04-25 15:48 ` Eric Blake
2011-04-22 20:10 ` Jonathan Nieder
2011-04-22 20:49 ` Sunil Mushran
2011-04-25 3:11 ` Valdis.Kletnieks
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=1303414954-3315-1-git-send-email-josef@redhat.com \
--to=josef@redhat.com \
--cc=hch@infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).