Re: Rename BTRfs to MuchSlowerFS ?
On Fri, 2011-09-16 at 05:16 +0700, Fajar A. Nugraha wrote: On Fri, Sep 16, 2011 at 2:37 AM, Felix Blanke felixbla...@gmail.com wrote: I'm using btrfs since one year now and it's quite fast. I don't feel any differences to other filesystems. Never tried a benchmark but for my daily work it's nice. Your workload must be light :) I recently repeatedly rsync whole partitions (30GB) without ill effects. (ok - first sync took whole 1s). The advantage to ext4 for me is the build in raid1 and the snapshots. I'm using the snapshot feature for my local backups. I like it because it's really easy and uses very few storage. A simple Snapshot - Rsync to a different disk - Snapshot script is the perfect local backup method. you've never used zfs have you :) For that purpose, think same feature as btrfs snapshot + rsync but without needing rsync. This can be very useful as the process of rsync determining what data to transfer can be quite CPU/disk intensive. Now I'm curious - how do zsf get data off the partition without rsync? Regards signature.asc Description: This is a digitally signed message part
Re: Rename BTRfs to MuchSlowerFS ?
On Fri, Sep 16, 2011 at 1:21 PM, Maciej Marcin Piechotka uzytkown...@gmail.com wrote: On Fri, 2011-09-16 at 05:16 +0700, Fajar A. Nugraha wrote: On Fri, Sep 16, 2011 at 2:37 AM, Felix Blanke felixbla...@gmail.com wrote: I'm using btrfs since one year now and it's quite fast. I don't feel any differences to other filesystems. Never tried a benchmark but for my daily work it's nice. Your workload must be light :) I recently repeatedly rsync whole partitions (30GB) without ill effects. (ok - first sync took whole 1s). Wait, you mean you sync 30GB data to another partition in one second? It should not be possible for single HDD no matter what the filesystem is. Unless you're using SSD or many HDD in raid. That's how I'm using btrfs btw, on SSD, so I pretty much don't see the slowness since the SSD is blazingly fast. Add to that the fact btrfs has the features I need (compression, snapshot), and more memory-efficient (compared to zfs), it's suitable for my needs. The advantage to ext4 for me is the build in raid1 and the snapshots. I'm using the snapshot feature for my local backups. I like it because it's really easy and uses very few storage. A simple Snapshot - Rsync to a different disk - Snapshot script is the perfect local backup method. you've never used zfs have you :) For that purpose, think same feature as btrfs snapshot + rsync but without needing rsync. This can be very useful as the process of rsync determining what data to transfer can be quite CPU/disk intensive. Now I'm curious - how do zsf get data off the partition without rsync? First hit on Google: http://www.markround.com/archives/38-ZFS-Replication.html As additinal info, zfs send/receive stream is at DMU layer, which (in over-simplified term) is similar to raw disk blocks in normal partition+ext4 setup. zfs keeps track of which blocks are used, so when given two different snapshot, it can easily find out which blocks are different. When using incremental send zfs only has to send those blocks. It doesn't have to explicitly re-examine which parts of the file is unmodified (thus not wasting disk, CPU, and network the way rsync does). IIRC there was a proposal in this list sometime ago on implementing similar functionality (send/receive) in btrfs. No actual working code (yet) that I know of though. -- Fajar -- 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: Rename BTRfs to MuchSlowerFS ?
On Fri, 2011-09-16 at 13:42 +0700, Fajar A. Nugraha wrote: On Fri, Sep 16, 2011 at 1:21 PM, Maciej Marcin Piechotka uzytkown...@gmail.com wrote: On Fri, 2011-09-16 at 05:16 +0700, Fajar A. Nugraha wrote: On Fri, Sep 16, 2011 at 2:37 AM, Felix Blanke felixbla...@gmail.com wrote: I'm using btrfs since one year now and it's quite fast. I don't feel any differences to other filesystems. Never tried a benchmark but for my daily work it's nice. Your workload must be light :) I recently repeatedly rsync whole partitions (30GB) without ill effects. (ok - first sync took whole 1s). Wait, you mean you sync 30GB data to another partition in one second? It should not be possible for single HDD no matter what the filesystem is. Unless you're using SSD or many HDD in raid. You misparse the sentence. First sync took 1s after rsync and next were much faster. Regards signature.asc Description: This is a digitally signed message part
[PATCH] Btrfs: fix pages truncation in btrfs_ioctl_clone()
It's a bug in commit f81c9cdc567cd3160ff9e64868d9a1a7ee226480
(Btrfs: truncate pages from clone ioctl target range)
We should pass the dest range to the truncate function, but not the
src range.
Also move the function before locking extent state.
Signed-off-by: Li Zefan l...@cn.fujitsu.com
---
fs/btrfs/ioctl.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 5492bb3..f6af8b0 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2237,6 +2237,10 @@ static noinline long btrfs_ioctl_clone(struct file
*file, unsigned long srcfd,
goto out_unlock;
}
+ /* truncate page cache pages from target inode range */
+ truncate_inode_pages_range(inode-i_data, destoff,
+ PAGE_CACHE_ALIGN(destoff + len) - 1);
+
/* do any pending delalloc/csum calc on src, one way or
another, and lock file content */
while (1) {
@@ -2253,10 +2257,6 @@ static noinline long btrfs_ioctl_clone(struct file
*file, unsigned long srcfd,
btrfs_wait_ordered_range(src, off, len);
}
- /* truncate page cache pages from target inode range */
- truncate_inode_pages_range(inode-i_data, off,
- ALIGN(off + len, PAGE_CACHE_SIZE) - 1);
-
/* clone data */
key.objectid = btrfs_ino(src);
key.type = BTRFS_EXTENT_DATA_KEY;
--
1.7.3.1
--
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
Raid0 and drive failure.
Good day. This is likely a newbie question, but I just need to confirm. If you have 3 x 100GB drives in RAID0 and one drive dies this will result in total data loss correct? Is there no way to loose only the data that resides (even partly) on the missing drive but retain the rest of the data ? Regards Henti -- 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: WARNING: at fs/btrfs/inode.c:2193 btrfs_orphan_commit_root+0xb0/0xc0 [btrfs]()
Hi Josef, after a quick test it seems that I do not hit this Warning any longer. But I got a new one. [ 5241.839951] [ cut here ] [ 5241.839974] WARNING: at fs/btrfs/extent-tree.c:5715 btrfs_alloc_free_block+0xac/0x330 [btrfs]() [ 5241.839979] Hardware name: MS-96B3 [ 5241.839982] Modules linked in: radeon ttm drm_kms_helper drm i2c_algo_bit psmouse k8temp sp5100_tco edac_core edac_mce_amd serio_raw shpchp i2c_piix4 lp parport ahci pata_atiixp libahci btrfs e1000e zlib_deflate libcrc32c [ 5241.840068] Pid: 1568, comm: kworker/0:1 Tainted: GW 3.1.0-rc6 #1 [ 5241.840072] Call Trace: [ 5241.840084] [81063d0f] warn_slowpath_common+0x7f/0xc0 [ 5241.840101] [81063d6a] warn_slowpath_null+0x1a/0x20 [ 5241.840133] [a002a9cc] btrfs_alloc_free_block+0xac/0x330 [btrfs] [ 5241.840152] [8110d35a] ? unlock_page+0x2a/0x40 [ 5241.840188] [a0059268] ? read_extent_buffer+0xa8/0x180 [btrfs] [ 5241.840222] [a0031c00] ? verify_parent_transid+0x160/0x160 [btrfs] [ 5241.840252] [a001a0d2] __btrfs_cow_block+0x122/0x4b0 [btrfs] [ 5241.840283] [a001a552] btrfs_cow_block+0xf2/0x1f0 [btrfs] [ 5241.840314] [a001cb88] push_leaf_left+0x108/0x180 [btrfs] [ 5241.840344] [a001fb78] btrfs_del_items+0x2b8/0x440 [btrfs] [ 5241.840379] [a00300c2] btrfs_del_csums+0x2d2/0x310 [btrfs] [ 5241.840415] [a00677a8] ? btrfs_tree_unlock+0x28/0xb0 [btrfs] [ 5241.840447] [a002597a] __btrfs_free_extent+0x48a/0x6f0 [btrfs] [ 5241.840480] [a0028c8d] run_clustered_refs+0x21d/0x840 [btrfs] [ 5241.840514] [a002937a] btrfs_run_delayed_refs+0xca/0x220 [btrfs] [ 5241.840551] [a0053576] ? btrfs_run_ordered_operations+0x1d6/0x200 [btrfs] [ 5241.840587] [a0038fa3] btrfs_commit_transaction+0x83/0x870 [btrfs] [ 5241.840605] [81012871] ? __switch_to+0x261/0x2f0 [ 5241.840622] [81086d70] ? wake_up_bit+0x40/0x40 [ 5241.840656] [a0039790] ? btrfs_commit_transaction+0x870/0x870 [btrfs] [ 5241.840691] [a00397af] do_async_commit+0x1f/0x30 [btrfs] [ 5241.840708] [8108110d] process_one_work+0x11d/0x430 [ 5241.840724] [81081dd9] worker_thread+0x169/0x360 [ 5241.840741] [81081c70] ? manage_workers.clone.21+0x240/0x240 [ 5241.840758] [81086616] kthread+0x96/0xa0 [ 5241.840775] [815f2434] kernel_thread_helper+0x4/0x10 [ 5241.840792] [81086580] ? flush_kthread_worker+0xb0/0xb0 [ 5241.840808] [815f2430] ? gs_change+0x13/0x13 [ 5241.840819] ---[ end trace c8a580615cad6cb5 ]--- Best Regards, Martin Am 15.09.2011 21:50, schrieb Josef Bacik: On Thu, Sep 15, 2011 at 11:44:09AM -0700, Sage Weil wrote: On Tue, 13 Sep 2011, Liu Bo wrote: On 09/11/2011 05:47 AM, Martin Mailand wrote: Hi I am hitting this Warning reproducible, the workload is a ceph osd, kernel ist 3.1.0-rc5. Have posted a patch for this: http://marc.info/?l=linux-btrfsm=131547325515336w=2 We're still seeing this with -rc6, which includes 98c9942 and 65450aa. I haven't looked at the reservation code in much detail. Is there anything I can do to help track this down? This should be taken care of with all my enospc changes. You can pull them down from my btrfs-work tree as soon as kernel.org comes back from the dead :). Thanks, Josef -- 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 -- 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: WARNING: at fs/btrfs/inode.c:2193 btrfs_orphan_commit_root+0xb0/0xc0 [btrfs]()
On 09/16/2011 10:09 AM, Martin Mailand wrote: Hi Josef, after a quick test it seems that I do not hit this Warning any longer. But I got a new one. Hmm looks like that may not be my newest stuff, is commit 57f499e1bb76ba3ebeb09cd12e9dac84baa5812b in there? Specifically look at __btrfs_end_transaction in transaction.c and see if the line trans-block_rsv = NULL; is before the first while() loop. Thanks, Josef -- 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: Raid0 and drive failure.
On Fri, Sep 16, 2011 at 05:06:03PM +0200, Henti Smith wrote: On Fri, Sep 16, 2011 at 4:49 PM, Leonidas Spyropoulos artafi...@gmail.com wrote: On Sep 16, 2011 1:25 PM, Henti Smith he...@geekware.co.za wrote: This is likely a newbie question, but I just need to confirm. If you have 3 x 100GB drives in RAID0 and one drive dies this will result in total data loss correct? Yes the data are lost. Read more on how raid 0 works. I have read on how raid 0 works, I was merely asking about the implementation of raid0 on btrfs. Is there no way to loose only the data that resides (even partly) on the missing drive but retain the rest of the data ? This is the more pertinent question, which it seem btrfs can't do currently. btrfs stripes its RAID-0 data across all available disks, so you'd lose approximately 1/3 of the data for each file. In some cases, you might get lucky and have a small file that resides entirely on the two undamaged disks. In that case, it *might* be possible to recover your data, but I think in general the amount of effort involved to get that degree of recovery is probably far outweighted by the use of your backups to restore all of the missing data... Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Are you the man who rules the Universe? Well, I --- try not to. signature.asc Description: Digital signature
Re: WARNING: at fs/btrfs/inode.c:2193 btrfs_orphan_commit_root+0xb0/0xc0 [btrfs]()
Hi Josef,
the commit is not in there, but the code looks like your post.
if (--trans-use_count) {
trans-block_rsv = trans-orig_rsv;
return 0;
}
trans-block_rsv = NULL;
while (count 4) {
unsigned long cur = trans-delayed_ref_updates;
trans-delayed_ref_updates = 0;
But on the other hand I am quite new to git, how could I get your latest
commit?
Best Regards,
Martin
Am 16.09.2011 16:37, schrieb Josef Bacik:
On 09/16/2011 10:09 AM, Martin Mailand wrote:
Hi Josef,
after a quick test it seems that I do not hit this Warning any longer.
But I got a new one.
Hmm looks like that may not be my newest stuff, is commit
57f499e1bb76ba3ebeb09cd12e9dac84baa5812b
in there? Specifically look at __btrfs_end_transaction in transaction.c
and see if the line
trans-block_rsv = NULL;
is before the first while() loop. Thanks,
Josef
--
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
--
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: Raid0 and drive failure.
This is the more pertinent question, which it seem btrfs can't do currently. btrfs stripes its RAID-0 data across all available disks, so you'd lose approximately 1/3 of the data for each file. In some cases, you might get lucky and have a small file that resides entirely on the two undamaged disks. In that case, it *might* be possible to recover your data, but I think in general the amount of effort involved to get that degree of recovery is probably far outweighted by the use of your backups to restore all of the missing data... That how I understood raid0 as well, so I do understand that, thank you. Henti -- 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/7] BTRFS: Fix lseek return value for error
On Thu, Sep 15, 2011 at 04:06:47PM -0700, Andi Kleen wrote:
From: Andi Kleen a...@linux.intel.com
Introduced by 9a4327ca1f45f82edad7dc0a4e52ce9316e0950c
I think this should go to Chris/Linus ASAP. But a slightly better
patch description wouldn't hurt either.
Also any reason you captialize BTRFS?
Signed-off-by: Andi Kleen a...@linux.intel.com
---
fs/btrfs/file.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index 3c3abff..7ec0a24 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -1818,19 +1818,17 @@ static loff_t btrfs_file_llseek(struct file *file,
loff_t offset, int origin)
case SEEK_DATA:
case SEEK_HOLE:
ret = find_desired_extent(inode, offset, origin);
- if (ret) {
- mutex_unlock(inode-i_mutex);
- return ret;
- }
+ if (ret)
+ goto error;
}
if (offset 0 !(file-f_mode FMODE_UNSIGNED_OFFSET)) {
ret = -EINVAL;
- goto out;
+ goto error;
}
if (offset inode-i_sb-s_maxbytes) {
ret = -EINVAL;
- goto out;
+ goto error;
}
/* Special lock needed here? */
@@ -1841,6 +1839,9 @@ static loff_t btrfs_file_llseek(struct file *file,
loff_t offset, int origin)
out:
mutex_unlock(inode-i_mutex);
return offset;
+error:
+ mutex_unlock(inode-i_mutex);
+ return ret;
}
const struct file_operations btrfs_file_operations = {
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
---end quoted text---
--
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: WARNING: at fs/btrfs/inode.c:2193 btrfs_orphan_commit_root+0xb0/0xc0 [btrfs]()
David Sterba wrote: On Thu, Sep 15, 2011 at 11:44:09AM -0700, Sage Weil wrote: On Tue, 13 Sep 2011, Liu Bo wrote: On 09/11/2011 05:47 AM, Martin Mailand wrote: Hi I am hitting this Warning reproducible, the workload is a ceph osd, kernel ist 3.1.0-rc5. Have posted a patch for this: http://marc.info/?l=linux-btrfsm=131547325515336w=2 We're still seeing this with -rc6, which includes 98c9942 and 65450aa. Me too, for the WARNING: at fs/btrfs/extent-tree.c:5711 btrfs_alloc_free_block+0x180/0x350 [btrfs]() FWIW, I'm seeing a slightly different case, while testing branch integration/btrfs-next (commit 2828cbd9620e03) from git://repo.or.cz/linux-2.6/btrfs-unstable.git merged into branch master (commit c455ea4f122d21) from git://github.com/torvalds/linux.git Under a heavy ceph write load, I see lots of these: [ 2369.797044] [ cut here ] [ 2369.801759] WARNING: at fs/btrfs/extent-tree.c:5751 use_block_rsv+0x177/0x180 [btrfs]() [ 2369.809864] Hardware name: X8DTH-i/6/iF/6F [ 2369.814062] Modules linked in: loop btrfs zlib_deflate lzo_compress ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack [ 2369.828671] btrfs: journal_info set but trans not join/nolock: 0x1 [ 2369.829040] ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp scsi_transport_iscsi rds ib_ipoib rdma_ucm rdma_cm ib_ucm ib_uverbs ib_umad ib_cm iw_cm ib_addr ipv6 ib_sa dm_mirror dm_region_hash dm_log dm_multipath scsi_dh dm_mod video sbs sbshc pci_slot battery acpi_pad ac kvm sg sd_mod mlx4_ib ib_mad ib_core mlx4_en joydev mpt2sas tpm_tis tpm scsi_transport_sas mlx4_core cxgb4 button serio_raw raid_class tpm_bios ata_piix libata scsi_mod i2c_i801 ioatdma ehci_hcd iTCO_wdt uhci_hcd i2c_core i7core_edac iTCO_vendor_support edac_core pcspkr rtc nfs nfs_acl auth_rpcgss fscache lockd sunrpc tg3 bnx2 igb dca e1000 [ 2369.889908] Pid: 23744, comm: kworker/19:3 Tainted: GW 3.1.0-rc6-00265-gf883c8c #33 [ 2369.898510] Call Trace: [ 2369.901026] [8104e02f] warn_slowpath_common+0x7f/0xc0 [ 2369.907046] [8104e08a] warn_slowpath_null+0x1a/0x20 [ 2369.912935] [a05c7fb7] use_block_rsv+0x177/0x180 [btrfs] [ 2369.919422] [a05d122d] btrfs_alloc_free_block+0x3d/0x220 [btrfs] [ 2369.926431] [810f1a01] ? __set_page_dirty_nobuffers+0xe1/0x150 [ 2369.933265] [a05ff3c1] ? read_extent_buffer+0xc1/0x1a0 [btrfs] [ 2369.940085] [a05bf58e] __btrfs_cow_block+0x11e/0x4d0 [btrfs] [ 2369.946737] [a0610091] ? btrfs_tree_lock+0x161/0x2c0 [btrfs] [ 2369.953391] [a05bfefa] btrfs_cow_block+0xea/0x200 [btrfs] [ 2369.959756] [a05c2b2f] btrfs_search_slot+0x31f/0x720 [btrfs] [ 2369.966362] [a05d3a9b] btrfs_del_csums+0x23b/0x320 [btrfs] [ 2369.972833] [a05cf41b] __btrfs_free_extent+0x49b/0x720 [btrfs] [ 2369.979660] [a05cf969] run_delayed_data_ref+0x159/0x160 [btrfs] [ 2369.986591] [a05cfa20] run_one_delayed_ref+0xb0/0xd0 [btrfs] [ 2369.993257] [a05cfb0f] run_clustered_refs+0xcf/0x240 [btrfs] [ 2369.28] [a05cfd58] btrfs_run_delayed_refs+0xd8/0x260 [btrfs] [ 2370.006937] [a05dde77] btrfs_commit_transaction+0x87/0x8b0 [btrfs] [ 2370.014238] [81072930] ? wake_up_bit+0x40/0x40 [ 2370.019710] [a05de6a0] ? btrfs_commit_transaction+0x8b0/0x8b0 [btrfs] [ 2370.027180] [a05de6bf] do_async_commit+0x1f/0x30 [btrfs] [ 2370.033578] [a05de6a0] ? btrfs_commit_transaction+0x8b0/0x8b0 [btrfs] [ 2370.041039] [8106c03f] process_one_work+0x13f/0x490 [ 2370.046950] [8106ddb7] worker_thread+0x187/0x3e0 [ 2370.052679] [8106dc30] ? manage_workers+0x120/0x120 [ 2370.058682] [810723a6] kthread+0x96/0xa0 [ 2370.063690] [8145c7f4] kernel_thread_helper+0x4/0x10 [ 2370.069695] [8145284a] ? retint_restore_args+0xe/0xe [ 2370.075720] [81072310] ? kthread_worker_fn+0x1d0/0x1d0 [ 2370.081919] [8145c7f0] ? gs_change+0xb/0xb [ 2370.087103] ---[ end trace a6d5cd679d4e46b9 ]--- I don't know if it matters, but I also see lots of this sort of thing: [ 2370.131721] btrfs: all snaps cleaned [ 2370.241382] btrfs: btrfs_clean_old_snapshots to process 1 old snaps [ 2370.275303] btrfs: btrfs_clean_old_snapshots to process 0 old snaps [ 2370.275306] btrfs: all snaps cleaned [ 2370.296461] btrfs: all snaps cleaned [ 2370.639211] btrfs: btrfs_clean_old_snapshots to process 1 old snaps [ 2370.688785] btrfs: all snaps cleaned [ 2370.811568] btrfs: journal_info set but trans not join/nolock: 0x1 [ 2370.830958] btrfs: btrfs_clean_old_snapshots to process 0 old snaps [ 2370.830962] btrfs: all snaps cleaned [ 2371.040634] btrfs: journal_info set but trans not join/nolock: 0x1 [ 2371.057286] btrfs: journal_info set but trans not join/nolock: 0x1 [ 2371.267641] btrfs: btrfs_clean_old_snapshots to process 1 old snaps [ 2371.285724] btrfs: journal_info set but trans not
Re: [PATCH] Btrfs: fix pages truncation in btrfs_ioctl_clone()
On Fri, 16 Sep 2011, Li Zefan wrote:
It's a bug in commit f81c9cdc567cd3160ff9e64868d9a1a7ee226480
(Btrfs: truncate pages from clone ioctl target range)
We should pass the dest range to the truncate function, but not the
src range.
Sigh... yes.
Also move the function before locking extent state.
Hmm, any reason? i_mutex protects us from a racing write(2), but what
about a racing mmap()? e.g.
cloner: truncates dest pages
writer: mmap - page_mkwrite locks extent, creates new dirty page, unlocks
cloner: locks extent, clones, unlocks extent
sage
Signed-off-by: Li Zefan l...@cn.fujitsu.com
---
fs/btrfs/ioctl.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 5492bb3..f6af8b0 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2237,6 +2237,10 @@ static noinline long btrfs_ioctl_clone(struct file
*file, unsigned long srcfd,
goto out_unlock;
}
+ /* truncate page cache pages from target inode range */
+ truncate_inode_pages_range(inode-i_data, destoff,
+PAGE_CACHE_ALIGN(destoff + len) - 1);
+
/* do any pending delalloc/csum calc on src, one way or
another, and lock file content */
while (1) {
@@ -2253,10 +2257,6 @@ static noinline long btrfs_ioctl_clone(struct file
*file, unsigned long srcfd,
btrfs_wait_ordered_range(src, off, len);
}
- /* truncate page cache pages from target inode range */
- truncate_inode_pages_range(inode-i_data, off,
-ALIGN(off + len, PAGE_CACHE_SIZE) - 1);
-
/* clone data */
key.objectid = btrfs_ino(src);
key.type = BTRFS_EXTENT_DATA_KEY;
--
1.7.3.1
--
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/7] BTRFS: Fix lseek return value for error
On Fri, Sep 16, 2011 at 11:48:15AM -0400, Christoph Hellwig wrote: On Thu, Sep 15, 2011 at 04:06:47PM -0700, Andi Kleen wrote: From: Andi Kleen a...@linux.intel.com Introduced by 9a4327ca1f45f82edad7dc0a4e52ce9316e0950c I think this should go to Chris/Linus ASAP. But a slightly better patch description wouldn't hurt either. Josef acked it earlier, but with a missing Chris the btrfs merge pipeline seems to be disfunctional at the moment. -Andi -- 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
long mount time
System info: -I have a 2TB hard drive with a GPT and the entire drive is formatted as btrfs. -It is 60% used. -It is mounted as /home -Kernel: 3.0.4 -Distro: Fedora 15 x86_64 -CPU: Xeon X3360 (quad core) 2.8ghz The mount time of the drive is very long. Systemd records it as 7440ms. Basically 50% of my boot time is waiting on btrfs to mount. My system is plenty fast and ext4 or xfs mounts are extremely fast. Is there anything that I can do to fix this or is this a btrfs feature? -- 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
Data consistency for un-opened files at crash time
Hi, Due to a recent crash of my PC which subsequently resulted in corruption of my btrfs partition, I set out to research about file system reliablity in general and btrfs in specific. I came across the numurous accounts of corruption due to the use of btrfs with dm-crypt. I also found Chris Mason's barrier test http://oss.oracle.com/~mason/barrier-test. Having tested ext4 FS with it, I could consistently corrupt it when on dm-crypt *with* barrier mount option on. As sad as it was finding about this issue, I decided to instead put a plain btrfs for my home directory and mount ecryptfs at the top of it for the time being. As for my backup btrfs partition which already has a lot of COW trees - about a year worth of backup, this isn't a possibility. I therefore devised a different plan, however, I need to ensure a certain characteristic of btrfs before going ahead with it: Let's assume we have a physical partition formatted as btrfs with no dm layers in play - so we know write-barriers work ok. We then put a large file (500GB) on it called apple. Using COW cp, we copy it to a new file called orange. Now if we open orange and start writing randomly in it and while writing, pull the power plug, is it gauranteed that when we mount the fs next time, *apple* is intact - both in terms of metadata and actual data? Cheers, Mansour -- 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
