http://blog.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://comments.gmane.org/gmane.comp.file-systems.btrfs/17596 <pre>* Fix typos and some grammar errors * Fix some arguments like &lt;id&gt; -&gt; &lt;subvolid&gt; so they are the same on the manpage and 'btrfs help' output * Add missing commands to manpage * Change manpage order to conform to 'btrfs help' output, which I find the more logical of the two Signed-off-by: Sami Liedes &lt;sami.liedes&lt; at &gt;iki.fi&gt; --- btrfs.c | 2 +- cmds-balance.c | 8 +-- cmds-filesystem.c | 2 +- cmds-inspect.c | 4 +- cmds-scrub.c | 8 +-- cmds-subvolume.c | 4 +- man/btrfs.8.in | 172 ++++++++++++++++++++++++++++++++--------------------- 7 files changed, 117 insertions(+), 83 deletions(-) diff --git a/btrfs.c b/btrfs.c index 88238d6..cf16cb8 100644 --- a/btrfs.c +++ b/btrfs.c &lt; at &gt;&lt; at &gt; -187,7 +187,7 &lt; at &gt;&lt; at &gt; const struct cmd_group btrfs_cmd_group; static const char * const cmd_help_usage[] = { "btrfs help [--full]", -"Dislay help information", +"Display help information", "", "--full display detailed help on every command", NULL diff --git a/cmds-balance.c </pre> Sami Liedes 2012-05-26T20:53:31 http://comments.gmane.org/gmane.comp.file-systems.btrfs/17595 <pre>Hi! I see that Linux 3.4 supports bigger metadata blocks for btrfs. Will using them allow a bigger number of hardlinks on a single file (i.e. the bug that has bitten at least git users on Debian[1,2], and BackupPC[3])? As far as I understand correctly, the problem has been that the hard links are stored in the same metadata block with some other metadata, so the size of the block is an inherent limitation? If so, I think it would be worth for me to try Btrfs again :) Sami [1] http://permalink.gmane.org/gmane.comp.file-systems.btrfs/13603 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642603 [3] https://bugzilla.kernel.org/show_bug.cgi?id=15762 </pre> Sami Liedes 2012-05-26T18:22:12 http://comments.gmane.org/gmane.comp.file-systems.btrfs/17594 <pre>The btrfs filesystem resize command defaults to only resizing the filesystem for devid 1, and must have a devid passed in to resize the filesystem for the other devices in the filesystem. Additionally the documentation lacked information on how to actually resize the underlying partition so this provides a little more detail. Signed-off-by: Shawn Bohrer &lt;shawn.bohrer&lt; at &gt;gmail.com&gt; --- cmds-filesystem.c | 4 ++-- man/btrfs.8.in | 17 +++++++++++------ 2 files changed, 13 insertions(+), 8 deletions(-) diff --git a/cmds-filesystem.c b/cmds-filesystem.c index 1f53d1c..00e4310 100644 --- a/cmds-filesystem.c +++ b/cmds-filesystem.c &lt; at &gt;&lt; at &gt; -456,10 +456,10 &lt; at &gt;&lt; at &gt; static int cmd_defrag(int argc, char **argv) } static const char * const cmd_resize_usage[] = { -"btrfs filesystem resize [+/-]&lt;newsize&gt;[gkm]|max &lt;path&gt;", +"btrfs filesystem resize [devid:][+/-]&lt;newsize&gt;[gkm]|[devid:]max &lt;path&gt;", "Resize a filesystem", "If 'max' is passed, the filesystem will occupy all available space", -"on the device.", +"on</pre> Shawn Bohrer 2012-05-26T17:57:55 http://comments.gmane.org/gmane.comp.file-systems.btrfs/17593 <pre></pre> FROM MRS SUSAN SHABANGU 2012-05-26T10:56:23 http://comments.gmane.org/gmane.comp.file-systems.btrfs/17589 <pre>Chris: Please pull git://git.jan-o-sch.net/btrfs-unstable for-chris for 3.5, it's a major improvement for the backref resolver and a good base to build qgroups and "btrfs send" onto. And, besides all other, its implications on existing code outside backref.c are very small, mostly added lines with no effect outside the backref resolver. This patch set is to provide reliable backref resolving on busy trees. The previous attempts to block certain tree modifications while we're resolving backrefs all ended up in (dead-) locking nightmares. What we now do is we record all the changes we make to fs trees while backref resolving is in progress into a tree modification log. During backref resolving we then merge the current state of the tree with the recorded modifications to get a consistent previous state of the tree. The first three commits are plain bug fixes, but the tree mod log cannot function without them. So they're included in this patch set. To only these three fixes, you can pull git://git.jan-o-</pre> Jan Schmidt 2012-05-26T10:59:34 http://comments.gmane.org/gmane.comp.file-systems.btrfs/17574 <pre> i am robothroli, Purchase manager from roli Merchant Ltd. We are Import/export Company based in taiwan. We are interested in purchasing your product and I would like to make an inquiry. Please inform me on: Sample availability and price Minimum order quantity FOB Prices Sincerely Purchase Manager robothroli -- 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> robothroli company 2012-05-25T13:45:54 http://comments.gmane.org/gmane.comp.file-systems.btrfs/17557 <pre>Hello, I would like to start a discussion on atime in Btrfs (and possibly other filesystems with snapshot support). As atime is updated on every access of a file or directory, we get many changes to the trees in btrfs that as always trigger cow operations. This is no problem as long as the changed tree blocks are not shared by other subvolumes. Performance is also not a problem, no matter if shared or not (thanks to relatime which is the default). The problems start when someone starts to use snapshots. If you for example snapshot your root and continue working on your root, after some time big parts of the tree will be cowed and unshared. In the worst case, the whole tree gets unshared and thus takes up the double space. Normally, a user would expect to only use extra space for a tree if he changes something. A worst case scenario would be if someone took regular snapshots for backup purposes and later greps the contents of all snapshots to find a specific file. This would touch all inodes in all trees an</pre> Alexander Block 2012-05-25T15:15:40 http://comments.gmane.org/gmane.comp.file-systems.btrfs/17556 <pre>The linux-joystick mailing list has been superseded by the linux-input list run at vger.kernel.org. See http://vger.kernel.org/vger-lists.html for information on the new list server (or consult your local oracle). Yours virtually, Martin Mares -- 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> Martin Mares 2012-05-25T14:59:24 http://comments.gmane.org/gmane.comp.file-systems.btrfs/17555 <pre>If cow_file_range_inline fails with ENOSPC we abort the transaction which isn't very nice. This really shouldn't be happening anyways but there's no sense in making it a horrible error when we can easily just go allocate normal data space for this stuff. Thanks, Signed-off-by: Josef Bacik &lt;josef&lt; at &gt;redhat.com&gt; --- fs/btrfs/inode.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index cd51968..46d8732 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c &lt; at &gt;&lt; at &gt; -257,10 +257,13 &lt; at &gt;&lt; at &gt; static noinline int cow_file_range_inline(struct btrfs_trans_handle *trans, ret = insert_inline_extent(trans, root, inode, start, inline_len, compressed_size, compress_type, compressed_pages); -if (ret) { +if (ret &amp;&amp; ret != -ENOSPC) { btrfs_abort_transaction(trans, root, ret); return ret; +} else if (ret == -ENOSPC) { +return 1; } + btrfs_delalloc_release_metadata(inode, end + 1 - start); btrfs_drop_extent_cache(inode, start, aligned_end -</pre> Josef Bacik 2012-05-25T14:10:30 http://comments.gmane.org/gmane.comp.file-systems.btrfs/17554 <pre>Ceph was hitting this race where we would remove an inode from the per-root orphan list before we would release the space we had reserved for the inode. We actually don't need a list or anything, we just need to make sure the root doesn't try to free up the orphan reserve until after the inodes have released their reservations. So use an atomic counter instead of a list on the root and only decrement the counter after we've released our reservation. I've tested this as well as several others and we no longer see the warnings that you would see while running ceph. Thanks, Btrfs: fix how we deal with the orphan block rsv Ceph was hitting this race where we would remove an inode from the per-root orphan list before we would release the space we had reserved for the inode. We actually don't need a list or anything, we just need to make sure the root doesn't try to free up the orphan reserve until after the inodes have released their reservations. So use an atomic counter instead of a list on the root and on</pre> Josef Bacik 2012-05-25T14:10:07 http://comments.gmane.org/gmane.comp.file-systems.btrfs/17553 <pre>Miao pointed this out while I was working on an orphan problem that messing with a bitfield where different ranges are protected by different locks doesn't work out right. Turns out we've been doing this forever where we have different parts of the bit field protected by either no lock at all or different locks which could cause all sorts of weird problems including the issue I was hitting. So instead make a runtime_flags thing that we use the normal bit operations on that are all atomic so we can keep having our no/different locking for the different flags and then make force_compress it's own thing so it can be treated normally. Thanks, Signed-off-by: Josef Bacik &lt;josef&lt; at &gt;redhat.com&gt; --- fs/btrfs/btrfs_inode.h | 30 ++++++++++++++++-------------- fs/btrfs/delayed-inode.c | 4 ++-- fs/btrfs/disk-io.c | 3 ++- fs/btrfs/extent-tree.c | 11 ++++++----- fs/btrfs/file.c | 12 ++++++------ fs/btrfs/inode.c | 28 ++++++++++++---------------- 6 files changed, 44 insertion</pre> Josef Bacik 2012-05-25T14:09:45 http://comments.gmane.org/gmane.comp.file-systems.btrfs/17551 <pre>"btrfs device stats" is used to retrieve and print the device stats. "btrfs device stats -z" is used to atomically retrieve, reset and print the stats. In order to share two utility functions between scrub and the dev stats code, these two functions are moved to utils.c and renamed. Since these functions are using open_file_or_dir(), and since the linking against utils.o and common.o was different, open_file_or_dir() was moved from common.c to utils.c. And since that function makes use of the function dirfd(3), the required XOPEN version was raised from 6 to 7. Changes v1-&gt;v2: - Remove a verbose printf() - Cast u64 to unsigned long long for printf() - Update the man page Changes v2-&gt;v3: - Rebase on Chris' current master branch - Split the patch into three seperate patches because after rebasing, open_file_or_dir() was moved and additional changes had been necessary Changes v3-&gt;v4: - Add padding at end of ioctl structure Changes v4-&gt;v5: - The statistic members in the ioctl are now organized as an array</pre> Stefan Behrens 2012-05-25T14:07:15 http://comments.gmane.org/gmane.comp.file-systems.btrfs/17546 <pre>Changes v1-v2: - Remove restriction that BTRFS_IOC_GET_DEVICE_STATS is a privileged operation - Cast u64 to unsigned long long for printf() Changes v2-v3: - Rebased on Chris' current master Changes v3-v4: - Add padding at end of ioctl structure Changes v4-v5: - The statistic members in the ioctl are now organized as an array of 64 bit values. Symbolic names for the array indexes are defined in an enum, which also defines the max value. This change makes it easier to add new statistic members in the future - Give ins_len = -1 to btrfs_search_slot() when an item might get deleted - Introduce a helper function for the repeated sequence stat_int() + dirty = 1 + stat_print() - Introduce a helper function for the code that shares the bio bi_private member for two pieces of information The goal is to detect when drives start to get an increased error rate, when drives should be replaced soon. Therefore statistic counters are added that count IO errors (read, write and flush). Additionally, the sof</pre> Stefan Behrens 2012-05-25T14:06:07 http://comments.gmane.org/gmane.comp.file-systems.btrfs/17544 <pre>Before the update_time inode operation was indroduced, it was not possible to prevent updates of atime on RO subvolumes. btrfs_update_time does now check if the root is RO and skip updating of atime. This patch requires the update_time patches from Josef Bacik. Signed-off-by: Alexander Block &lt;ablock84&lt; at &gt;googlemail.com&gt; --- fs/btrfs/inode.c | 26 +++++++++++++++++++++----- fs/inode.c | 3 +++ 2 files changed, 24 insertions(+), 5 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 54ae3df..b48db5a 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c &lt; at &gt;&lt; at &gt; -4470,14 +4470,30 &lt; at &gt;&lt; at &gt; int btrfs_dirty_inode(struct inode *inode) static int btrfs_update_time(struct inode *inode, struct timespec *now, int flags) { -if (flags &amp; S_VERSION) +struct btrfs_root *root = BTRFS_I(inode)-&gt;root; +int did_update = 0; + +if (flags &amp; S_VERSION) { inode_inc_iversion(inode); -if (flags &amp; S_CTIME) +did_update = 1; +} +if (flags &amp; S_CTIME) { inode-&gt;i_ctime = *now; -if (flags &amp; S_MTIME) +</pre> Alexander Block 2012-05-25T12:50:43 http://comments.gmane.org/gmane.comp.file-systems.btrfs/17539 <pre>Hi Chris, Hi Josef, Hi Btrfs-List and all other Btrfs-devs that I've forgot, is there a chance we'll see a xz file-compression support in Btrfs anytime soon ? I'm sure folks have been waiting for additional compression support besides gzip and lzo (bzip2 seems out of question due to its slowness, there's pbzip2 but that's not included in the kernel). This would be a really nice bonus due to the processors getting faster and SSD usage is more and more widespread - add an efficient implementation and we would have a fast, extremely efficient and feature-rich filesystem. My current situation is that several of my harddrives are almost completely full - even with forced gzip-compression - so I thought I'd asked whether there was any change in the near future ahead. There's fusecompress but that probably wouldn't end up being as stable as a btrfs with xz/lzma-support. Thanks for your consideration and your work on Btrfs ! It got significantly more stable compared to the past :) (I use it mainly for som</pre> Matt 2012-05-24T21:28:42 http://comments.gmane.org/gmane.comp.file-systems.btrfs/17537 <pre>Hello, if a snapshot was created with -r and thus is read only, accessing files in it will update the atime. I would expect that atime is not updated on ro snapshots. I tried to find out where the ro check is missing. The problem seems to be that the vfs is only checking the mount, super block and i_flags. As it has no clue about subvolumes, it never checks them. My temporary solution for me to continue working is atm the patch at the end of this mail. Is anyone with more vfs experience able to fix this in a better way? Thanks, Alex. diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 3524978..6f126e0 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c &lt; at &gt;&lt; at &gt; -115,6 +115,10 &lt; at &gt;&lt; at &gt; void btrfs_update_iflags(struct inode *inode) inode-&gt;i_flags |= S_NOATIME; if (ip-&gt;flags &amp; BTRFS_INODE_DIRSYNC) inode-&gt;i_flags |= S_DIRSYNC; + + if (btrfs_root_readonly(ip-&gt;root)) { + inode-&gt;i_flags |= S_NOATIME; + } } -- To unsubscribe from this list: send the line</pre> Alexander Block 2012-05-24T17:12:11 http://comments.gmane.org/gmane.comp.file-systems.btrfs/17529 <pre>Good morning, I currently have a single-disk setup where I want to use btrfs filesystem. Yet, I expect to add additional disks to this system in the future. Those disks shall be visible to the OS like a single disk, i.e. using multi-disk feature in btrfs. While data shall be striped among those disks in the future, meta data shall be mirrored for better fault tolerance (loss of some data is acceptable, while loss of all data is not acceptable). btrfs supports multi-disk setups and even adding additional devices at a later point of time. Thus, it is my preferred choice. However, I am puzzled how the mkfs.btrfs command must be parametrized to have RAID1 for meta data and RAID0 for data with just a single disk / partition. Could I simply do mkfs.btrfs -m raid1 -d raid0 /dev/sdaX (where X is the partition number) ? Unfortunately, I do not have a disk to test it right now. The disk I am planning to use is with the post service still :) . Searching the Web could not reveal a similar scenario. All multi-disk ex</pre> Björn Wüst 2012-05-24T06:05:23 http://comments.gmane.org/gmane.comp.file-systems.btrfs/17527 <pre>Two files in the different subvolumes may have the same inode id, so The rb-tree which is used to manage the defragment object must take it into account. This patch fix this problem. Signed-off-by: Miao Xie &lt;miaox&lt; at &gt;cn.fujitsu.com&gt; --- fs/btrfs/file.c | 45 +++++++++++++++++++++++++++++++++++---------- 1 files changed, 35 insertions(+), 10 deletions(-) diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index 23364c1..3d22fd0 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c &lt; at &gt;&lt; at &gt; -65,6 +65,21 &lt; at &gt;&lt; at &gt; struct inode_defrag { int cycled; }; +static int __compare_inode_defrag(struct inode_defrag *defrag1, + struct inode_defrag *defrag2) +{ +if (defrag1-&gt;root &gt; defrag2-&gt;root) +return 1; +else if (defrag1-&gt;root &lt; defrag2-&gt;root) +return -1; +else if (defrag1-&gt;ino &gt; defrag2-&gt;ino) +return 1; +else if (defrag1-&gt;ino &lt; defrag2-&gt;ino) +return -1; +else +return 0; +} + /* pop a record for an inode into the defrag tree. The lock * must be held already * &lt; at &gt;&lt; at &gt; -87,9 +102,9 &lt; at &gt;&lt; at &gt; static void __btrfs_add_inode_</pre> Miao Xie 2012-05-24T02:42:19 http://comments.gmane.org/gmane.comp.file-systems.btrfs/17525 <pre>If cow_file_range_inline fails with ENOSPC we abort the transaction which isn't very nice. This really shouldn't be happening anyways but there's no sense in making it a horrible error when we can easily just go allocate normal data space for this stuff. Thanks, Signed-off-by: Josef Bacik &lt;josef&lt; at &gt;redhat.com&gt; --- fs/btrfs/inode.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index cd51968..46d8732 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c &lt; at &gt;&lt; at &gt; -257,10 +257,13 &lt; at &gt;&lt; at &gt; static noinline int cow_file_range_inline(struct btrfs_trans_handle *trans, ret = insert_inline_extent(trans, root, inode, start, inline_len, compressed_size, compress_type, compressed_pages); -if (ret) { +if (ret &amp;&amp; ret != -ENOSPC) { btrfs_abort_transaction(trans, root, ret); return ret; +} else if (ret == -ENOSPC) { +return 1; } + btrfs_delalloc_release_metadata(inode, end + 1 - start); btrfs_drop_extent_cache(inode, start, aligned_end -</pre> Josef Bacik 2012-05-23T20:08:49 http://comments.gmane.org/gmane.comp.file-systems.btrfs/17520 <pre>During unmount, it could happen that the integrity checker printed a warning message "attempt to free ... on umount which is not yet iodone" which turned out to be a false positive. Signed-off-by: Stefan Behrens &lt;sbehrens&lt; at &gt;giantdisaster.de&gt; --- fs/btrfs/check-integrity.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c index d85b9d1..b5e9891 100644 --- a/fs/btrfs/check-integrity.c +++ b/fs/btrfs/check-integrity.c &lt; at &gt;&lt; at &gt; -3338,7 +3338,7 &lt; at &gt;&lt; at &gt; void btrfsic_unmount(struct btrfs_root *root, btrfsic_block_link_free(l); } -if (b_all-&gt;is_iodone) +if (b_all-&gt;is_iodone || b_all-&gt;never_written) btrfsic_block_free(b_all); else printk(KERN_INFO "btrfs: attempt to free %c-block" </pre> Stefan Behrens 2012-05-23T16:12:55 http://comments.gmane.org/gmane.comp.file-systems.btrfs/17517 <pre>Hi, I'm trying mount many subvolume during boot via fstab: UUID=xxx /usr btrfs subvol=usr,ro,nodev 0 0 UUID=xxx /home btrfs subvol=home,nodev,nosuid 0 0 UUID=xxx /var btrfs subvol=var,nodev 0 0 UUID=xxx /var/tmp btrfs subvol=var-tmp,nodev,noexec,nosuid 0 0 But only the first one is mounted. When try to mount the others subvolumes, I get this error: mount: /dev/sda3 already mounted or /home busy mount: according to mtab, /dev/sda3 is mounted on /usr mount: /dev/sda3 already mounted or /var busy mount: according to mtab, /dev/sda3 is mounted on /usr mount: mount point /var/tmp does not exist I'm using linux kernel 3.3.6 and mount 2.20 in Debian 7. </pre> Rogerio Bastos 2012-05-23T15:00:02 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.file-systems.btrfs