Re: [PATCH 1/2] fs: add SEEK_HOLE and SEEK_DATA flags
Sunil Mushran wrote:
On 04/22/2011 04:50 AM, Eric Blake wrote:
That blog also mentioned the useful idea of adding FIND_HOLE and
FIND_DATA, not implemented in Solaris, but which could easily be
provided as additional lseek constants in Linux to locate the start of
the next chunk without repositioning and which could ease application
programmer's life a bit. After all, cp wants to know where data ends
without repositioning (FIND_HOLE), read() that much data which
repositions in the process, then skip to the next chunk of data
(SEEK_DATA) - two lseek() calls per iteration if we have 4 constants,
but 3 per iteration if we only have SEEK_HOLE and have to manually rewind.
while(1) {
read(block);
if (block_all_zeroes)
lseek(SEEK_DATA);
}
What's wrong with the above? If this is the case, even SEEK_HOLE
is not needed but should be added as it is already in Solaris.
Apart from the obvious waste of effort (scanning *all* data for zeros
is cheap but not free if the file is mostly non-hole zeros), you can't
do a pread() version of the above in parallel over different parts of
the same file/device.
My problem with FIND_* is that we are messing with the well understood
semantics of lseek().
fcntl() looks a better fit for FIND_HOLE/DATA anyway.
-- Jamie
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Btrfs: fix missing mutex_unlock in btrfs_del_dir_entries_in_log()
(2011/04/22 21:45), David Sterba wrote:
Hi,
On Fri, Apr 22, 2011 at 06:05:40PM +0900, Tsutomu Itoh wrote:
It is necessary to unlock mutex_lock before it return an error when
btrfs_alloc_path() fails.
good catch! however I suggest to move the mutex_lock after the
allocation and check, it'll be semantically equivalent to your change,
but a bit readable. quick grep for btrfs_alloc_path usage showed that
it's quite common to do path allocation/check before any real work is
started.
Even if mutex_lock() move to after btrfs_alloc_path(),
we should call btrfs_end_log_tarns().
So I chose 'goto out_unlock'.
Thanks,
Tsutomu
david
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index c50271a..f997ec0 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -2209,8 +2209,10 @@ int btrfs_del_dir_entries_in_log(struct
btrfs_trans_handle *trans,
log = root-log_root;
path = btrfs_alloc_path();
-if (!path)
-return -ENOMEM;
+if (!path) {
+err = -ENOMEM;
+goto out_unlock;
+}
mutex_lock(...);
di = btrfs_lookup_dir_item(trans, log, path, dir-i_ino,
name, name_len, -1);
@@ -2271,6 +2273,7 @@ int btrfs_del_dir_entries_in_log(struct
btrfs_trans_handle *trans,
}
fail:
btrfs_free_path(path);
+out_unlock:
mutex_unlock(BTRFS_I(dir)-log_mutex);
if (ret == -ENOSPC) {
root-fs_info-last_trans_log_full_commit = trans-transid;
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Read Only snapshots
Hi, btrfs-progs patches for read only snapshots aren't in Chris repository yet but btrfs already has support for that in place so, someone forgot about this? It appears that some new patches are coming to Chris btrfs-progs (new tmp branch) so this was a nice opportunity to get those patches in. Thanks David Morgado -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] fs: add SEEK_HOLE and SEEK_DATA flags
On Thu, 21 Apr 2011 15:42:33 EDT, Josef Bacik said: -SEEK_HOLE: this moves the file pos to the nearest hole in the file from the given position. Do we want the semantic to be the nearest hole? Or did we really want the next hole? Loops like a bullet loaded in the chamber and pointed at the programmer's foot if they aren't allowing for the fact that this can go *backwards* in the file if the closest hole is towards the beginning. Good way to end up in an infinite loop or other messy... Consider the obvious implementation of skip over a hole - lseek(SEEK_HOLE), lseek(SEEK_DATA). and start reading data because we've skipped over the hole. Wrong - the second seek may have gone backwards if the data was only 4K away but the hole was 64K in size... pgpN3MtjIn6I1.pgp Description: PGP signature
Re: writes got stuck
On Tue, 19 Apr 2011 05:08:05 -0700 Chris Mason wrote: Excerpts from Cheng Shao's message of 2011-04-18 17:49:29 -0400: Hi there, I'm periodically having issues with btrfs running in a Ubuntu VM using VirtualBox. After the VM has been running for a while (a couple days), any write operation seems getting stuck. The read seems totally fine. I tried a simple dd of a 4M file and it got stuck after writing 131K worth of data. I don't know if this is btrfs related, or it is due to some bug in VritualBox. Could you guys provide information on how to debug this (collecting logs, getting dumps etc.)? Thanks a lot! Which kernel are you running? Not reproducible with Linux 2.6.38.2-9.fc15.x86_64, Fedora 15 beta2, VirtualBox 4.06 on a Mac OS X host. Unrelated to btrfs but related to VirtualBox write hang, I did experience numerous hangs during installation of F15, which were apparently* resolved with kernel parameter clocksource=jiffies which is not related to btrfs, and was not previously required for F14 with earlier versions of VirtualBox. Chris Murphy * I say apparently with a sample of 8 failures without the option and 1 success with the option.-- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
