http://permalink.gmane.org/gmane.comp.file-systems.btrfs hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26386 <pre>Signed-off-by: Wang Shilong &lt;wangshilong1991&lt; at &gt;gmail.com&gt; --- print-tree.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/print-tree.c b/print-tree.c index aae47a9..c1d8d18 100644 --- a/print-tree.c +++ b/print-tree.c &lt; at &gt;&lt; at &gt; -355,8 +355,10 &lt; at &gt;&lt; at &gt; static void print_root(struct extent_buffer *leaf, int slot) (unsigned long long)btrfs_root_generation(&amp;root_item)); if (root_item.generation == root_item.generation_v2) { -uuid_unparse(root_item.uuid, uuid_str); -printf("\t\tuuid %s\n", uuid_str); +if (count_bytes(root_item.uuid, BTRFS_UUID_SIZE, 0) != BTRFS_UUID_SIZE) { +uuid_unparse(root_item.uuid, uuid_str); +printf("\t\tuuid %s\n", uuid_str); +} if (count_bytes(root_item.parent_uuid, BTRFS_UUID_SIZE, 0) != BTRFS_UUID_SIZE) { uuid_unparse(root_item.parent_uuid, uuid_str); printf("\t\tparent_uuid %s\n", uuid_str); </pre> Wang Shilong 2013-06-18T03:52:06 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26385 <pre>From: Josef Bacik &lt;jbacik&lt; at &gt;fusionio.com&gt; Patch "Btrfs: remove btrfs_sector_sum structure" introduced a problem that we copied the checksum value to the wrong address when doing relocation. The reason is: It is very likely that one ordered extent has two or more checksum structures to keep the relative checksum value, and -&gt;bytenr in each checksum structure should point to the start of its extent, not the start of the ordered extent. Fix it. Signed-off-by: Josef Bacik &lt;jbacik&lt; at &gt;fusionio.com&gt; Signed-off-by: Miao Xie &lt;miaox&lt; at &gt;cn.fujitsu.com&gt; --- fs/btrfs/relocation.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c index 35c0cf7..e3108e5 100644 --- a/fs/btrfs/relocation.c +++ b/fs/btrfs/relocation.c &lt; at &gt;&lt; at &gt; -4410,11 +4410,13 &lt; at &gt;&lt; at &gt; int btrfs_reloc_clone_csums(struct inode *inode, u64 file_pos, u64 len) if (ret) goto out; +disk_bytenr = ordered-&gt;start; while (!list_empty(&amp;list)) { sums = list_entry(list.next, struct btrfs_ordered_sum, list); </pre> Miao Xie 2013-06-18T03:13:37 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26384 <pre>Any comments? Thanks Miao On thu, 13 Jun 2013 20:22:17 +0800, Miao Xie wrote: -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Miao Xie 2013-06-18T02:59:11 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26383 <pre> Loan Syndicacion Am AFG Guaranty Trust Bank, zu strukturieren wir Kreditlinien treffen Sie unsere Kunden spezifischen geschäftlichen Anforderungen und einen deutlichen Mehrwert für unsere Kunden Unternehmen. eine Division der AFG Finance und Private Bank plc. Wenn Sie erwägen, eine große Akquisition oder ein Großprojekt sind, können Sie brauchen eine erhebliche Menge an Kredit. AFG Guaranty Trust Bank setzen können zusammen das Syndikat, das die gesamte Kredit schnürt für Sie. Als Bank mit internationaler Reichweite, sind wir gekommen, um Darlehen zu identifizieren Syndizierungen als Teil unseres Kerngeschäfts und durch spitzte diese Zeile aggressiv sind wir an einem Punkt, wo wir kommen, um als erkannt haben Hauptakteur in diesem Bereich. öffnen Sie ein Girokonto heute mit einem Minimum Bankguthaben von 500 £ und Getup zu £ 10.000 als Darlehen und auch den Hauch einer Chance und gewann die Sterne Preis von £ 500.000 in die sparen und gewinnen promo in may.aply jetzt. mit dem Folowin</pre> AFG GTBANK LOAN 2013-06-17T19:28:00 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26382 <pre>btrfs filesystem label can work on a mounted filesystem, also on a multi-devices filesystem. And the restriction of label name is changed, too. The man page should be updated accordingly. Signed-off-by: Guangyu Sun &lt;guangyu.sun&lt; at &gt;oracle.com&gt; --- man/btrfs.8.in | 17 ++++------------- 1 file changed, 4 insertions(+), 13 deletions(-) diff --git a/man/btrfs.8.in b/man/btrfs.8.in index af7df4d..1da4ff1 100644 --- a/man/btrfs.8.in +++ b/man/btrfs.8.in &lt; at &gt;&lt; at &gt; -263,22 +263,13 &lt; at &gt;&lt; at &gt; it with the new desired size. When recreating the partition make sure to use the same starting disk cylinder as before. .TP -\fBfilesystem label\fP\fI &lt;dev&gt; [newlabel]\fP -Show or update the label of a filesystem. \fI&lt;dev&gt;\fR is used to identify the -filesystem. +\fBfilesystem label\fP\fI [&lt;device&gt;|&lt;mountpoint&gt;] [newlabel]\fP +Show or update the label of a filesystem. \fI[&lt;device&gt;|&lt;mountpoint&gt;]\fR is used +to identify the filesystem. If a \fInewlabel\fR optional argument is passed, the label is changed. The following constraints exi</pre> Guangyu Sun 2013-06-17T21:45:23 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26381 <pre>Hello Josef On Mon, Jun 17, 2013 at 11:21 PM, Josef Bacik &lt;jbacik&lt; at &gt;fusionio.com&gt; wrote: I just gave it a try, but wasn't successful, it seems… Kernel still crashes. Maybe checkout the screenphotos at http://goo.gl/DWkRH or http://imgur.com/a/00pTx Thanks, Alexander -- =&gt; Google+ =&gt; http://plus.skwar.me &lt;== =&gt; Chat (Jabber/Google Talk) =&gt; a.skwar&lt; at &gt;gmail.com &lt;== -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Alexander Skwar 2013-06-17T21:43:02 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26380 <pre> Pull down my tree git://github.com/josefbacik/btrfs-progs.git and build and run the fsck in there and see if it's a bit more friendly. Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Josef Bacik 2013-06-17T21:21:32 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26379 <pre>This has plagued us forever and I'm so over working around it. When we truncate down to a non-page aligned offset we will call btrfs_truncate_page to zero out the end of the page and write it back to disk, this will keep us from exposing stale data if we truncate back up from that point. The problem with this is it requires data space to do this, and people don't really expect to get ENOSPC from truncate() for these sort of things. This also tends to bite the orphan cleanup stuff too which keeps people from mounting. To get around this we can just move this into btrfs_cont_expand() to make sure if we are truncating up from a non-page size aligned i_size we will zero out the rest of this page so that we don't expose stale data. This will give ENOSPC if you try to truncate() up or if you try to write past the end of isize, which is much more reasonable. This fixes xfstests generic/083 failing to mount because of the orphan cleanup failing. Thanks, Signed-off-by: Josef Bacik &lt;jbacik&lt; at &gt;fusionio.com&gt; --- fs</pre> Josef Bacik 2013-06-17T21:19:24 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26378 <pre>Hello I think, I somewhat destroyed my btrfs filesystem on my Ubuntu 13.04 kernel 3.8.0-25-lowlatency system. It got destroyed, because the system was hanging for some other reason and I had to remove power... When I try to mount my filesystem (there's only one, with a few subfilesystems), the system crashes. Also btrfsck dies; always like this: a&lt; at &gt;ask-home:~$ sudo /btrfs-progs.dev/bin/btrfsck /dev/ssd/Data parent transid verify failed on 33327525888 wanted 53973 found 53972 parent transid verify failed on 33327525888 wanted 53973 found 53972 Ignoring transid failure Checking filesystem on /dev/ssd/Data UUID: 7d2eb10f-aced-4d41-bb7f-7badbf075b6a checking extents checking fs roots root 325 inode 31590 errors 400 extent buffer leak: start 33327525888 len 4096 *** Error in `btrfs check': corrupted double-linked list: 0x00000000007a2600 *** a&lt; at &gt;ask-home:~$ /btrfs-progs.dev/bin/btrfs version Btrfs v0.20-rc1-253-g7854c8b-dirty btrfsck always dies with a corrupted double-linked list. When the system crashes</pre> Alexander Skwar 2013-06-17T21:08:26 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26377 <pre> Awesome thanks Josef. Is it ok to include this patch as well, it implements the semantics that Gabriel and I talked about. The patch is also on top of the same git tree I have referenced in the original e-mails. Btw, let me know if you want/need help writing an xfs test for this. --Mark -- Mark Fasheh From: Mark Fasheh &lt;mfasheh&lt; at &gt;suse.de&gt; btrfs-extent-same: allow root to always dedupe This will allow end users to run dedupe against their readonly snapshots - a common method for making backups of btrfs subvolumes. Since it is impossible for root to get a rw file descriptor on such a snapshot, this enables dedupe from a privileged account to proceed with read access. Non root accounts still have the same access restrictions - they cannot dedupe without write access to the file. Signed-off-by: Mark Fasheh &lt;mfasheh&lt; at &gt;suse.de&gt; --- fs/btrfs/ioctl.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 9351b69..68931b9 100644 --- a/fs/btrfs/ioctl.c</pre> Mark Fasheh 2013-06-17T20:04:45 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26375 <pre>Hi, my laptop with a btrfs on dm-crypt on SSD freezed today shortly after resuming from suspend (it doesn't normally do that). I was running a self compiled 3.9.6 at this point. There should be around 20 of 114 GiB free on the file system and it was probably created with 16K leaf size. After rebooting, mounting the rootfs didn't work anymore. I made a copy of the disk and am now trying to fix it using my desktop. Trying to mount it with -o recovery on 3.10-rc6 triggers the following bug: I presume the "btrfs_recover_log_trees" line is a good sign for my data? I have daily backups of 99% of the data, but would have to reinstall some distro. Btrfsck from git master (650e656a) spits out the following, before crashing: [ ... snip, many similar errors ... ] I also took a picture when I first saw the problems directly after the reboot and it showed an additional BUG. It is reproducible with the self compiled kernel, but not with the Fedora 18 3.9.5 kernel. Maybe because Fedora doesn't compile with CONFIG_PR</pre> Michael Zugelder 2013-06-17T19:10:27 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26374 <pre> &gt; Quoting Dave Jones (2013-06-17 14:20:06) &gt; &gt; On Mon, Jun 17, 2013 at 01:39:42PM -0400, Chris Mason wrote: &gt; &gt; &gt; Quoting Dave Jones (2013-06-17 09:49:55) &gt; &gt; &gt; &gt; Hit this while running this script in a loop.. &gt; &gt; &gt; &gt; https://github.com/kernelslacker/io-tests/blob/master/setup.sh &gt; &gt; &gt; &gt; [34385.251507] ------------[ cut here ]------------ &gt; &gt; &gt; &gt; [34385.254068] WARNING: at fs/btrfs/inode.c:7961 btrfs_destroy_inode+0x265/0x2e0 [btrfs]() &gt; &gt; &gt; &gt; &gt; &gt; Thanks Dave, how long did you have to run the script to trigger it? &gt; &gt; &gt; &gt; &gt; &gt; -chris &gt; &gt; &gt; &gt; Judging by the timestamp, about 9 hours. This is on a 3 disk (sata) &gt; &gt; (oldish) quad opteron. Might repro faster on a more modern machine. &gt; &gt; Exactly how did you run it? I want to make sure I'm matching your &gt; config. while [ 1 ]; do setup.sh done You'll need to set DISK1 etc variables at the top of the script to point to at least 3 disks for it to scribble over. you'll also need fsx and fsstress in /usr/local/bin. Think that's all.</pre> Dave Jones 2013-06-17T18:58:10 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26372 <pre>This patch does two things. First we no longer explicitly read in the blocks we're trying to readahead. For things like balance_level we may never actually use the blocks so this just adds uneeded latency, and balance_level and split_node will both read in the blocks they care about explicitly so if the blocks need to be waited on it will be done there. Secondly we no longer drop the path if we do readahead, we just set the path blocking before we call reada_for_balance() and then we're good to go. Hopefully this will cut down on the number of re-searches. Thanks, Signed-off-by: Josef Bacik &lt;jbacik&lt; at &gt;fusionio.com&gt; --- fs/btrfs/ctree.c | 46 +++++++++------------------------------------- 1 files changed, 9 insertions(+), 37 deletions(-) diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c index c85cde7..c32d03d 100644 --- a/fs/btrfs/ctree.c +++ b/fs/btrfs/ctree.c &lt; at &gt;&lt; at &gt; -2178,12 +2178,8 &lt; at &gt;&lt; at &gt; static void reada_for_search(struct btrfs_root *root, } } -/* - * returns -EAGAIN if it had to drop the path, or zer</pre> Josef Bacik 2013-06-17T18:25:54 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26370 <pre>This patch does two things, first it only does one call to btrfs_buffer_uptodate() with the gen specified instead of once with 0 and then again with gen specified. The other thing is to call btrfs_read_buffer() on the buffer we've found instead of dropping it and then calling read_tree_block(). This will keep us from doing yet another radix tree lookup for a buffer we've already found. Thanks, Signed-off-by: Josef Bacik &lt;jbacik&lt; at &gt;fusionio.com&gt; --- fs/btrfs/ctree.c | 47 ++++++++++++++++++++--------------------------- 1 files changed, 20 insertions(+), 27 deletions(-) diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c index 1c9dc71..c85cde7 100644 --- a/fs/btrfs/ctree.c +++ b/fs/btrfs/ctree.c &lt; at &gt;&lt; at &gt; -2359,35 +2359,28 &lt; at &gt;&lt; at &gt; read_block_for_search(struct btrfs_trans_handle *trans, tmp = btrfs_find_tree_block(root, blocknr, blocksize); if (tmp) { /* first we do an atomic uptodate check */ -if (btrfs_buffer_uptodate(tmp, 0, 1) &gt; 0) { -if (btrfs_buffer_uptodate(tmp, gen, 1) &gt; 0) { -/* - * we found a</pre> Josef Bacik 2013-06-17T17:47:03 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26368 <pre>Hit this while running this script in a loop.. https://github.com/kernelslacker/io-tests/blob/master/setup.sh [34385.251507] ------------[ cut here ]------------ [34385.254068] WARNING: at fs/btrfs/inode.c:7961 btrfs_destroy_inode+0x265/0x2e0 [btrfs]() [34385.257275] Modules linked in: vmw_vsock_vmci_transport vmw_vmci vsock bridge 8021q garp stp mrp raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 xfs btrfs xor raid6_pq libcrc32c zlib_deflate tun hidp fuse cmtp kernelcapi rfcomm bnep l2tp_ppp l2tp_netlink l2tp_core nfnetlink ipt_ULOG can_raw phonet scsi_transport_iscsi ipx p8023 p8022 irda af_802154 caif_socket caif crc_ccitt rds af_key appletalk psnap pppoe pppox af_rxrpc ppp_generic slhc nfc rose netrom atm llc2 ax25 llc can_bcm x25 can raid0 kvm_amd snd_hda_codec_realtek kvm snd_hda_intel snd_hda_codec microcode snd_pcm pcspkr serio_raw btusb edac_core snd_page_alloc snd_timer bluetooth snd soundcore rfkill r8169 mii sr_mod cdrom pata_atiixp radeon backlight drm_kms_helper ttm [3</pre> Dave Jones 2013-06-17T13:49:55 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26367 <pre> - run defrag on all desired files with -czlib david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> David Sterba 2013-06-17T15:16:27 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26366 <pre> Hi, I'm afraid the above won't work, cause balance is not aware of the compression so that it won't decompress the data. thanks, liubo -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Liu Bo 2013-06-17T02:11:25 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26365 <pre> Your analysis at the last section is right, so the right process is: Task1Task2 |start_transaction(TRANS_START)| |-wait_current_trans(blocked=0, so it doesn't wait)| |-join_transaction()| |--lock(trans_lock)| |--can_join_transaction() YES| ||-btrfs_commit_transaction() ||--blocked=1 ||--in_commit=1 |--extwriter_counter_inc()| |--unlock(trans_lock)| ||--lock(trans_lock) ||--... ||--unlock(trans_lock) ||--... ||--wait_event(extwriter== 0); ||--btrfs_flush_all_pending_stuffs() The problem you worried can not happen. Anyway, it is not good that the "blocked/in_commit" check is not synchronized with joining a transaction. So I modified the relative code in this patchset. Miao -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Miao Xie 2013-06-17T01:51:33 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26364 <pre>scrub device /dev/sda3 (id 1) done scrub started at Mon Jun 17 06:00:01 2013 and finished after 781 seconds total bytes scrubbed: 76.31GB with 2 errors error details: super=2 corrected errors: 0, uncorrectable errors: 0, unverified errors: 0 It's on an Intel 120G SSD running the Debian 3.8-trunk-amd64 kernel. </pre> Russell Coker 2013-06-17T01:07:33 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26363 <pre>I have a btrfs filesystem mounted with "compress=lzo" now. I'd like to see how much space would I save by converting it to zlib. Would it be possible to convert lzo compression to zlib compression with the following: - mount the filesystem with "compress=zlib" - run balance - when balance finishes, the data would be compressed with zlib Would this work as above, or do I have to copy the data out and back to convert from lzo compression to zlib compression? </pre> Tomasz Chmielewski 2013-06-16T17:16:53 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26362 <pre>Hi Miao, On Thu, Jun 13, 2013 at 6:08 AM, Miao Xie &lt;miaox&lt; at &gt;cn.fujitsu.com&gt; wrote: I have a doubt about this point with your new code. Example: Task1 - external writer Task2 - transaction kthread Task1 Task2 |start_transaction(TRANS_START) | |-wait_current_trans(blocked=0, so it doesn't wait) | |-join_transaction() | |--lock(trans_lock) | |--can_join_transaction() YES | | |-btrfs_commit_transaction() | |--blocked=1 | |--in_commit=1 | |--wait_event(extwriter== 0); | |--btrfs_flush_all_pending_stuffs() | | |--extwriter_counter_inc() | |--unlock(trans_lock) | | | lock(trans_lock) | | tra</pre> Alex Lyakas 2013-06-16T10:38:42 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.file-systems.btrfs