Re: sendfile(2) not killable on btrfs
On Wed, 6 Jan 2016 06:08:46 PM Akihiro Suda wrote: > However, it is still not killable on btrfs. Your bugzilla entry is for the 4.2 kernel in the current Ubuntu, but this patch was only merged into the mainline for at v4.3-rc6-123-g296291c so unless it was backported by Canonical it won't be present. Could you test with the 4.3 kernel please? http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.3.3-wily/ cheers! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: Porting BTRFS to user space
On Wed, 8 Apr 2015 12:27:57 PM Hugo Mills wrote: (NFS, Ceph, Gluster certainly work this way. I would be surprised if any of the others out there at the moment didn't work like that). GPFS has its own underlying filesystem format, you can upgrade the format on the fly with mmchfs once all your GPFS nodes are at the same minimum version. Painful IBM URL follows: http://www-01.ibm.com/support/knowledgecenter/#!/SSFKCN_4.1.0/com.ibm.cluster.gpfs.v4r1.gpfs100.doc/bl1adm_fsmigissues.htm All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: btrfs_inode_item's otime?
On 15/01/15 21:48, David Sterba wrote: Chandan, please drop the btrfs_inode_otime helper and resend. Thanks. Thanks! Sorry I'd had no further time to look at this, I've been fully committed with $DAY_JOB and on a number of projects with our local community observatory (if anyone is in/visiting Melbourne and into astronomy ping me for details). All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: btrfs_inode_item's otime?
On Tue, 6 Jan 2015 10:47:00 PM Chris Samuel wrote: On Mon, 5 Jan 2015 06:21:52 PM Lennart Poettering wrote: It should be easy to initialize it to the mtime when the inode is first created... This I agree with, well worth doing anyway. I'll see if I can knock up a patch. Sadly it appears that the btrfs code sets mtime/ctime/atimeat inode creation via the normal filesystem inode structure, not through it's own, and as that doesn't include otime I'm afraid it's out of my league. Worth a shot though! All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: btrfs_inode_item's otime?
On Mon, 5 Jan 2015 06:21:52 PM Lennart Poettering wrote: Is this on purpose, or simply an oversight? The only hint I can see that it's deliberate is the comment in fs/btrfs/send.c that says: /* TODO Add otime support when the otime patches get into upstream */ However... It should be easy to initialize it to the mtime when the inode is first created... This I agree with, well worth doing anyway. I'll see if I can knock up a patch. All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: I need to P. are we almost there yet?
On Wed, 31 Dec 2014 09:27:14 AM ashf...@whisperpc.com wrote: I see this as a CRITICAL design flaw. The reason for calling it CRITICAL is that System Administrators have been trained for 20 years that RAID-10 can usually handle a dual-disk failure, but the BTRFS implementation has effectively ZERO chance of doing so. I suspect this is a knock-on effect of the fact that (unless this has changed recently IIRC) RAID-1 with btrfs will only mirrors data over two drives, no matter how many you add to an array. -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: Can BTRFS handle XATTRs larger than 4K?
On Sat, 20 Dec 2014 01:38:43 AM Chris Murphy wrote: I'm feeling too lazy to actually go look for evidence of this; but I made a file system a while ago with 64KB node/leafsize and ran into a bug I reported for send/receive. I'm pretty sure this was related to xattr being limited to nodesize, and I'm also pretty sure it got fixed. But I'm not sure whether the problem was on the send or receive side, and I'm not sure when. I suspect it's this commit and it implies that it's limited to the leafsize: commit 4395e0c4da486f007dcb45b0336427be7ec08ab1 Author: Filipe Manana fdman...@suse.com Date: Wed Aug 20 10:45:45 2014 +0100 Btrfs: send, lower mem requirements for processing xattrs Maximum xattr size can be up to nearly the leaf size. For an fs with a leaf size larger than the page size, using kmalloc requires allocating multiple pages that are contiguous, which might not be possible if there's heavy memory fragmentation. Therefore fallback to vmalloc if we fail to allocate with kmalloc. Also start with a smaller buffer size, since xattr values typically are smaller than a page. Reported-by: Chris Murphy li...@colorremedies.com Signed-off-by: Filipe Manana fdman...@suse.com Signed-off-by: Chris Mason c...@fb.com -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: Can BTRFS handle XATTRs larger than 4K?
On Mon, 22 Dec 2014 10:38:04 PM Chris Samuel wrote: I suspect it's this commit and it implies that it's limited to the leafsize: Forgot to mention that looks like it should be in 3.17 and later. -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: General Question: ctime, mtime, and xattrs
On Fri, 5 Dec 2014 03:28:58 PM Robert White wrote: I've been thinking ctime is/was (still) create time. It seems that somewhere in the last couple decades it became change time; Or that I picked up that incorrect create time idea back in the UNIX Sys V R 3 days and just never had cause to think about it again... Sadly there's never been a creation time in Linux that you can get with a standard system call, there was an attempt 4-5 years ago to get xstat merged that would include creation time from filesystems that support it (like ext4) but it never went anywhere (for a variety of reasons). LWN article on the patch set: https://lwn.net/Articles/394298/ Linus knocking it back: https://lkml.org/lkml/2010/7/22/249 FreeBSD has: st_birthtim Time when the inode was created. No idea when that was added! All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: btrfs balance segfault, kernel BUG at fs/btrfs/extent-tree.c:7727
On Sat, 25 Oct 2014 09:41:27 PM Rich Freeman wrote: So, there is something else in 3.17.1 that causes this problem. I did see mention of an extent error of some kind on the lists and I don't have that patch - I believe it is planned for 3.17.2. There are currently 13 patches for btrfs queued for 3.17.2: queue-3.17/btrfs-add-missing-compression-property-remove-in-btrfs_ioctl_setflags.patch queue-3.17/btrfs-cleanup-error-handling-in-build_backref_tree.patch queue-3.17/btrfs-don-t-do-async-reclaim-during-log-replay.patch queue-3.17/btrfs-don-t-go-readonly-on-existing-qgroup-items.patch queue-3.17/btrfs-fix-a-deadlock-in-btrfs_dev_replace_finishing.patch queue-3.17/btrfs-fix-and-enhance-merge_extent_mapping-to-insert-best-fitted-extent-map.patch queue-3.17/btrfs-fix-build_backref_tree-issue-with-multiple-shared-blocks.patch queue-3.17/btrfs-fix-race-in-wait_sync-ioctl.patch queue-3.17/btrfs-fix-the-wrong-condition-judgment-about-subset-extent-map.patch queue-3.17/btrfs-fix-up-bounds-checking-in-lseek.patch queue-3.17/btrfs-try-not-to-enospc-on-log-replay.patch queue-3.17/btrfs-wake-up-transaction-thread-from-sync_fs-ioctl.patch queue-3.17/revert-btrfs-race-free-update-of-commit-root-for-ro-snapshots.patch You can grab them here: http://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/tree/queue-3.17 Hope this helps! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: unexplainable corruptions 3.17.0
On Mon, 20 Oct 2014 10:01:56 AM Marc Dietrich wrote: so fixes would be tagged earlier this way and merged automaticly. I don't think there's a lot automatic about stable, Greg K-H merges patches into a git tree here: http://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git As you can see since last night he pulled in a bunch of btrfs fixes into that based upon what Chris Mason emailed out yesterday. commit 2792dbfd1e02a70a8eef7e0cc3f44cb77d6c100f Author: Greg Kroah-Hartman gre...@linuxfoundation.org Date: Mon Oct 20 07:08:43 2014 +0800 3.17-stable patches added patches: btrfs-add-missing-compression-property-remove-in-btrfs_ioctl_setflags.patch btrfs-cleanup-error-handling-in-build_backref_tree.patch btrfs-don-t-do-async-reclaim-during-log-replay.patch btrfs-don-t-go-readonly-on-existing-qgroup-items.patch btrfs-fix-a-deadlock-in-btrfs_dev_replace_finishing.patch btrfs-fix-and-enhance-merge_extent_mapping-to-insert-best-fitted-extent-map.patch btrfs-fix-build_backref_tree-issue-with-multiple-shared-blocks.patch btrfs-fix-race-in-wait_sync-ioctl.patch btrfs-fix-the-wrong-condition-judgment-about-subset-extent-map.patch btrfs-fix-up-bounds-checking-in-lseek.patch btrfs-try-not-to-enospc-on-log-replay.patch btrfs-wake-up-transaction-thread-from-sync_fs-ioctl.patch revert-btrfs-race-free-update-of-commit-root-for-ro-snapshots.patch (there are also a bunch going in for 3.10, 3.14 and 3.16 too) -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: strange 3.16.3 problem
Hiya Russell, On Sat, 18 Oct 2014 02:54:19 PM Russell Coker wrote: # find . -name *546 ./1412233213.M638209P10546 # ls -l ./1412233213.M638209P10546 ls: cannot access ./1412233213.M638209P10546: No such file or directory Does: find . -name *546 -ls work at all? -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: unexplainable corruptions 3.17.0
On Fri, 17 Oct 2014 02:09:30 PM Rich Freeman wrote: Just for clarity - when can we expect to see these in the kernel? The stable kernel rules say: https://www.kernel.org/doc/Documentation/stable_kernel_rules.txt # - It or an equivalent fix must already exist in Linus' tree (upstream). So until Linus merges the revert into the mainline kernel it cannot go into a stable release, and he's not merged it yet. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: unexplainable corruptions 3.17.0
On Sat, 18 Oct 2014 06:32:49 PM Chris Samuel wrote: So until Linus merges the revert into the mainline kernel it cannot go into a stable release, and he's not merged it yet. It was merged last night. -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: BUG_ON spams /var/log/messages with the same msg full
On Mon, 1 Sep 2014 09:37:54 PM Toralf Förster wrote: Ah thx, it seems that fix does not made it in -rc3, so -rc4 would be a better choice for a re-test, or ? It all depends on what Chris Mason sends to Linus, and what Linus chooses to accept. Your best bet is to watch the mailing list for the PULL requests to Linus and any response, and pull Linus's git tree to see what lands when. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: superblock checksum mismatch after crash, cannot mount
On Sun, 24 Aug 2014 01:08:53 PM Leen Besselink wrote: tip for basically any Linux filesystem, especially on Flash-based storage and also btrfs: - use noatime (if you aren't doing that already, don't know if that is the default in btrfs) Since 2.6.30 (5 years old now) the kernel has defaulted to mounting filesystems with relatime not atime so it's not as bad as it used to be. This is from the mount manual page. relatime Update inode access times relative to modify or change time. Access time is only updated if the previous access time was earlier than the current modify or change time. (Similar to noatime, but doesn't break mutt or other applications that need to know if a file has been read since the last time it was modified.) Since Linux 2.6.30, the kernel defaults to the behavior provided by this option (unless noatime was specified), and the strictatime option is required to obtain traditional semantics. In addition, since Linux 2.6.30, the file's last access time is always updated if it is more than 1 day old. All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: Using Btrfs with Ubuntu 14.04
On Tue, 12 Aug 2014 09:46:38 AM Cyril Scetbon wrote: Can you tell me if there are any pitfalls to use Btrfs under Ubuntu 14.04 (Btrfs 3.12). 14.04 is using the 3.13 kernel and (so far) has seemed stable enough for me. YMMV. ;-) cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: Unrecoverable errors when the btrfs file system was modified outside the running OS
On Mon, 4 Aug 2014 01:29:49 AM rocwhite168 wrote: being able to recover at least somewhat in this situation seems to be a desired feature for any file system. I would add that only specially designed clustered/distributed filesystems will survive this sort of accident. All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: Scan not being performed properly on boot
On Mon, 4 Aug 2014 01:31:42 PM Russell Coker wrote: Is BTRFS supported in that version of Ubuntu? Out of the box a fresh 14.04 install onto btrfs worked fine for me on two different sets of hardware. 13.10 the same on a third piece of hardware. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: ENOSPC with mkdir and rename
On Mon, 4 Aug 2014 09:14:19 AM Peter Waller wrote: All of this is *very* surprising. Hmm, it shouldn't be, the ENOSPC issues are well known and have been discussed here for years. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: ENOSPC with mkdir and rename
On Mon, 4 Aug 2014 11:56:46 AM Clemens Eisserer wrote: Which doesn't protect the *average* user from running into issues like this. No, but they need to be aware of it. Just because it has been discussed, doesn't mean nothing can/should be done about it Indeed, and a lot of work has been done over the years on it and it's a lot better than it used to be. :-) cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: ENOSPC with mkdir and rename
Hi Peter, On Mon, 4 Aug 2014 11:59:19 AM Peter Waller wrote: On 4 August 2014 11:50, Chris Samuel ch...@csamuel.org wrote: To be honest I'm not sure I'd suggest btrfs for production use at all at present, it's only recently been unmarked as experimental and to be honest I feel that was premature. Thanks for the honest answer. That's OK, I am enthusiastic about btrfs (being a pre-mainline merge user), but I don't think it serves it well to signal that it's more ready than it actually is. There are very positive signals out there which I had perhaps taken too literally. I'd love to see it become ready, there are a lot of things about BTRFS which appeal greatly. So I hope I'm helping by trying to make it clear the problems that I encountered. Oh indeed, please don't take my brief replies as being anything other than brief due to preparing to do some astronomy! :-) All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: Blocked tasks on 3.15.1, raid1 btrfs is no ends of trouble for me
On Fri, 18 Jul 2014 05:44:57 PM Marc MERLIN wrote: Sorry, this may be a bit misleading. I actually lost 2 filesystems that were raid0 on top of dmcrypt. Stupid question I know, but does this happen without dmcrypt? cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: btrfs loopback problems
On Mon, 7 Jul 2014 11:20:30 AM Qu Wenruo wrote: As Chris Mason mentioned, fixed in the following patch: https://patchwork.kernel.org/patch/4143821/ That should probably go to -stable (if it hasn't already), especially as 3.14 is a new LTS kernel. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC signature.asc Description: This is a digitally signed message part.
Re: A question about subvolumes
On Sat, 5 Jul 2014 12:06:18 PM Austin S Hemmelgarn wrote: I'm pretty certain that recent versions of the GNU Coreutils will automatically try a reflink for cp if the underlying filesystem is BTRFS. I'm not 100% certain about this as I've just aliases cp to 'cp --reflink=auto' on all my systems. Doesn't appear to be the case in the current git I'm afraid. http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/cp.c You could choose to patch cp.c to change: x-reflink_mode = REFLINK_NEVER; to: x-reflink_mode = REFLINK_AUTO; to change the default should you wish to. All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC signature.asc Description: This is a digitally signed message part.
Re: Blocked tasks on 3.15.1
On Fri, 27 Jun 2014 05:20:41 PM Duncan wrote: If I'm not mistaken the fix for the 3.16 series bug was: ea4ebde02e08558b020c4b61bb9a4c0fcf63028e Btrfs: fix deadlocks with trylock on tree nodes. That patch applies cleanly to 3.15.2 so if it is indeed the fix it should probably go to -stable for the next 3.15 release.. Unfortunately my test system died a while ago (hardware problem) and I've not been able to resurrect it yet. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC signature.asc Description: This is a digitally signed message part.
Re: BTRFS hangs - possibly NFS related?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 25 May 2014 12:42:32 PM kim-bt...@bluemoose.org.uk wrote: Any ideas of what I can do to help debug it...? Looking at that output it seems that all those blocked processes are in congestion_wait() in mm/backing-dev.c, the comments for which say: /** * congestion_wait - wait for a backing_dev to become uncongested * @sync: SYNC or ASYNC IO * @timeout: timeout in jiffies * * Waits for up to @timeout jiffies for a backing_dev (any backing_dev) to exit * write congestion. If no backing_devs are congested then just wait for the * next write to be completed. */ The blocked tasks are: kswapd0 smbd (which correlates with what you've said before) ShFolders (is this something local?) ATA-0 (I suspect a kernel process handling that device) Interestingly there are no calls to congestion_wait() in fs/btrfs so those blocked tasks are blocked accessing other filesystems. One thing that would be interesting is to see the wchan of processes blocked in device wait state when you're in that situation. Something like this should do it: ps -eo pid,user,stat,wchan:30,comm | fgrep -w D Is this system under memory pressure at the time these happen? All the best, Chris - -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEVAwUBU4HjtI1yjaOTJg85AQKPYAgAlI7elWEx0YxPqABFmS3cUVIgTskxFL6/ ha7G1wxIxeqxhx1x1cLE3oKsCAhJlrwXd6cB8e0Kmu2280fCa/N9uqdJaMq+E8ha VU0K0D6lAd2lJP9L1XVI2hlAO8YEwuFpe5ebYk//1LERsZxkPVJSrIntVKvG8aCR 9fHLa9W7Pscn9oOyC2Nvh/z4FAAHu0/QWj/uuA8cOUX0FRyHrsqhhi3a+zHNJkOo vB6nfd/TWJXXDTRO6Og9ozW8InvAvpuG0NNOVSVQd10xc09qLMaP98cBBhisFji/ r3RZ0GiyW4SlYjQWhfxP9eBtZlsQD8lZMGEXHPyzlHZrJzMfjQjJvw== =h6xh -END PGP SIGNATURE- -- 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: Sending incremental backup causes deadlock (3.14.3)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Josef, On Fri, 9 May 2014 01:22:27 PM Josef Bacik wrote: Known problem, fixed in 3.15-rc1. Thanks, Is the fix suitable for -stable too? All the best, Chris - -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEVAwUBU23dko1yjaOTJg85AQLPwggAw6zkv1svCb5PToUiwhjwArArlaa/hLjR n0YgbWpfACpvL0iDrbbEKwIn6cBBOwe/wm5vSF/JoAmgRk8UWkxZrsItjBXt9XjR Z1O/SJFUjJILxbiKNx4qjEHVKNZfBuPb5fBkcU9iRUzeAXzJUGfC5oWBx29fi187 7G+gJ/axApMdtbNkVyAzRdoS8ehDJgpb95dhxmuSv30d9sYvHlt6k+Ye6ulTO4V2 q2XUQoxTxs5HRACWToZiB5T89GQgJSppLxvRCYlHIYxOpjHvOQDkVvHnIHhVtJhl ko0TwiQwXNVxwQ825y5T07vhlifWlRx0QHysoqBWP4Qwlfdf1cyjtw== =xkLU -END PGP SIGNATURE- -- 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: URGENT: my laptop's boot ssd btrfs crashed, what do you need off it?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 10 May 2014 09:26:22 AM Tom Kuther wrote: The same thing happened to me just right now. Also on my SSD, also at fs/btrfs/inode.c:4927 btrfs_invalidate_inode, also on 3.14. Was your kernel tainted in any way at that point? Not saying it's to blame, but it'd be interesting to correlate with Marc's report. cheers, Chris - -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEVAwUBU24QvI1yjaOTJg85AQK09ggAlpnRyRvsI+Nah37vjUPohjdoPWl0pgux 271bhXeWnKxekvOrS9A3DFDKiQg8TkI8BIVcp+mIprEPnQRqm3VaH6fkzGeccskl f3C18Y56MbJwyH6qw3nltVRoexrceeb9ojVZDcAEhRs2IHI+xPzaCW9PqLYP+qc+ VkSy6sVpJBahUlVJchy2f2nhNXnPV3Rj+DTBaDoy6mKS7L8kIP2Sb0e5a6HcK2i4 gS06yeZTk7vCDP19UpvByNknS2tWDn8t4HZSJFTdwMDjpfRRssUELGhh4uL+N6u+ QtEOgfuimlnXcETOvFc/aaq8Ls8f0nTTRwVWu5+hw+NmKOdkrwKUtQ== =dM5D -END PGP SIGNATURE- -- 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: btrfs cleaner failure - fs/btrfs/extent-tree.c:5748 (3.14.0)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Marc, On Fri, 9 May 2014 03:36:59 PM Marc MERLIN wrote: Oh, I missed that. May 2 14:23:06 legolas kernel: [283268.319035] CPU: 0 PID: 25726 Comm: watchdog/0 Tainted: GW3.14.0-amd64-i915-preempt-20140216 #2 This is weird because I don't use any 3rd party binary modules. There's actually a bunch of reasons a kernel can be tainted. Right now, I do see: legolas:~# cat /proc/sys/kernel/tainted 512 IIUC that's an array of bit flags, and that value means you've had a previous kernel warning at that point according to: https://www.kernel.org/doc/Documentation/sysctl/kernel.txt # tainted: # # Non-zero if the kernel has been tainted. Numeric values, # which can be ORed together: # [...] # 512 - A kernel warning has occurred. Best of luck! Chris - -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEVAwUBU21vOo1yjaOTJg85AQLJDwf/QOxRt0f5KqPbhknn8x0XyUQ5upC8PbzD FoDHAkKV7tCUGQ6ZmCufBUKi0beNHNE3YKXlld8zLjlYpyV5lCZIgP3XvjQ/A4pZ Vq+XKiqddaZHOFnjQuk9kseqXJaeH7Vr90xz2D92lcRb3NY6yoD2sdFMhAeN43vh 23stzC2Ybr79NFELWPCL3MTFL4qZrAY/4KFFKDQEZsNHMEJW2zJXX841lFsTXJwO 1Ggsi3WzNCJMo+GHRqH+9Gyb4ICk7u7FABHo+y/dShTGnxAh5/8zMnKidlSfCdzd APKPMrydKEX+O+Fm3zDcKg8gER3FJtWKCyHXfW+zyORTMbxiH5QK5Q== =q69d -END PGP SIGNATURE- -- 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: How to debug very very slow file delete? (btrfs on md-raid5)
On Tue, 25 Mar 2014 09:41:42 AM Marc MERLIN wrote: 4 hours to stat 700K files. That's bad... Even 11mn to restat them just to count them looks bad too. One way to get an idea of where that's happening is to run the command with strace -c to build up a table of times spent in each system call, usecs per call (average) and number of calls. Best of luck! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC signature.asc Description: This is a digitally signed message part.
Re: [GIT PULL] Btrfs part two
Hi Chris, On Fri, 11 Apr 2014 12:50:26 PM Chris Mason wrote: The most important changes here are from Josef, fixing a btrfs regression in 3.14 that can cause corruptions in the extent allocation tree when snapshots are in use. Will these regression fixes go to stable too? cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC signature.asc Description: This is a digitally signed message part.
Re: BTRFS setup advice for laptop performance ?
On Mon, 7 Apr 2014 11:11:11 AM Austin S Hemmelgarn wrote: This is because every other filesystem (except ZFS) doesn't use COW semantics. There is an interesting article on LWN at the moment (subscriber only for the next day or two, but if you can afford it I'd suggest considering subscribing) about the Linux Storage, Filesystem, and Memory Management (LSFMM) Summit discussions around the impact of the new Shingle Magnetic Recording (SMR) drives that may change that. Given these devices are likely to have large sequential write only areas it's going to make getting existing Linux filesystems to work on them interesting, in the section on Dave Chinners filesystem part of the discussion it says: # Any of the existing filesystems that do not support copy-on-write (COW) # cannot really be optimized for SMR, he said, because you can't overwrite # data in sequential zones. That would mean adding COW to ext4 and XFS, # Chinner said. https://lwn.net/Articles/592091/ There's some background to SMR drives (available to all) from the LSFMM here: https://lwn.net/Articles/591782/ All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC signature.asc Description: This is a digitally signed message part.
Re: BTRFS setup advice for laptop performance ?
On Fri, 4 Apr 2014 10:02:27 AM Swâmi Petaramesh wrote: However I'm still concerned with chronic BTRFS dreadful performance and still find that BRTFS degrades much over time even with periodic defrag and best practices etc. That's odd, I've been running it on laptops with SSDs since 2009 and haven't hit this yet.I'm a KDE user too (though not using Kmail/Akonadi on the machines in question). Sorry I can't do much more than say works for me, but that happens to be the case.. :-( cheers! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC signature.asc Description: This is a digitally signed message part.
Re: discard synchronous on most SSDs?
On Sat, 15 Mar 2014 04:25:05 PM Chris Samuel wrote: I wonder if it would be possible to use that knowledge to extend the smartctl's --identify functionality to report this? After reading the SATA 3.1 spec I believe that smartctl *can* indicate if a drive claims to support SATA 3.1 NCQ TRIM, thus: $ sudo smartctl --identify /dev/sdb | fgrep 'Trim bit in DATA SET MANAGEMENT' 169 0 1 Trim bit in DATA SET MANAGEMENT command supported $ If that command returns nothing then it's not reported as supported (and I've tested that). You can get the same info with hdparm -I. Of course, as Martin said, that doesn't necessarily mean the kernel is using that reported ability. My puzzle now is that I have two SSD drives that report supporting NCQ TRIM (one confirmed via product info) but report only supporting SATA 3.0 not 3.1. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC signature.asc Description: This is a digitally signed message part.
Re: discard synchronous on most SSDs?
On Thu, 13 Mar 2014 09:39:02 PM Chris Murphy wrote: smartctl -a or -x will tell you what SATA revision is in place. The queued trim support is in SATA Rev 3.1. I'm not certain if this requires only the drive to support that revision level, or both controller and drive. Both I'd say as I believe it's the controller that has to issue it to the drive, and the drive needs to understand it. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC signature.asc Description: This is a digitally signed message part.
Re: discard synchronous on most SSDs?
Hi Marc, On Thu, 13 Mar 2014 10:17:50 PM Marc MERLIN wrote: I'm not sure I'm seeing this, which field is that? I *think* you want smartctl -i instead, and look for the field that says something like: ATA Version is: ATA8-ACS, ACS-2 T13/2015-D revision 3 So if my understanding is correct that says it's just rev. 3.0 so TRIM for this is synchronous. Good luck! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC signature.asc Description: This is a digitally signed message part.
Re: discard synchronous on most SSDs?
On Fri, 14 Mar 2014 06:33:24 PM Chris Samuel wrote: I *think* you want smartctl -i instead, and look for the field that says something like: ATA Version is: ATA8-ACS, ACS-2 T13/2015-D revision 3 Late night, cut and pasted the wrong line of output, mine says: SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) Of course that's what the drive is reporting it supports, I'm not sure whether that's the result of what has been negotiated between the controller and drive or purely what the drive supports. To get more information from smartctl you can use the --identify=wb option instead of -i and that should give you a lot more detail about what then drives claims to (and not to) support. On the version in Kubuntu 13.10 (6.1+svn3812-1) it only reports 3 things regarding TRIM for my drives. chris@quad:/tmp$ sudo smartctl --identify=wb -d sat /dev/sdb | egrep -i 'trim| discard' 69 14 1 Deterministic data after trim supported 69 5 0 Trimmed LBA range(s) returning zeroed data supported 169 0 1 Trim bit in DATA SET MANAGEMENT command supported I'm currently doing a git clone of their SVN repo to see if there's any new functionality that will gather any more information. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC signature.asc Description: This is a digitally signed message part.
Re: Understanding btrfs and backups
On Sun, 9 Mar 2014 03:30:44 PM Duncan wrote: While I realize that was in reference to the up in flames comment and presumably if there's a need to worry about that, offsite backup /is/ of some value, for some people, offsite backup really isn't that valuable. Actually I missed that comment altogether, it was really just an illustration of why people should think about it - and then come to a decision about whether or not it makes sense for them. In your case maybe not, but for me (and my wife) it certainly does. All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC signature.asc Description: This is a digitally signed message part.
Re: Understanding btrfs and backups
On Fri, 7 Mar 2014 04:14:16 PM Sander wrote: But if the filesystem or underlaying disk goes up in flames, the snapshots are toast as well. So you need additional backups, preferably not on the same hardware, for real protection against data loss. ...and don't forget to think about off-site backups too. http://www.flickr.com/photos/94482242@N00/7746409996/ cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: btrfs send kernel error btrfs_compare_tree
On Sat, 8 Mar 2014 06:40:52 PM Travis Cross wrote: $ uname -a Linux 3.13-1-amd64 #1 SMP Debian 3.13.5-1 (2014-03-04) x86_64 GNU/Linux Not sure if it will help, but Chris Mason has a git tree with currently 4 fixes against 3.13.5: https://git.kernel.org/cgit/linux/kernel/git/mason/linux-btrfs.git/log/?h=for-stable-3.13 Best of luck! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC signature.asc Description: This is a digitally signed message part.
Re: [GIT PULL] Btrfs
On Sun, 2 Feb 2014 01:28:07 AM Filipe David Manana wrote: One of the kbuild test robots reported this a few days ago too. The following patch, sent shortly after the robot's warning, fixes it: https://patchwork.kernel.org/patch/3554671/ I can confirm that fixes the bug for me (with a different config than my usual to trigger the bug) at v3.13-11307-g5cb480f. Much obliged! Tested-by: Chris Samuel ch...@csamuel.org All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: btrfsck does not fix
On Tue, 14 Jan 2014 10:17:19 AM Chris Murphy wrote: -c 9 is max compression although I don't know what algorithm btrfs-image uses off hand. If I use xz on it, 193MB becomes 192MB. Be interesting to generate the same image without compression in btrfs-image and then xz it, in case it can do better with the raw data. cheers! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: btrfs raid1 and btrfs raid10 arrays NOT REDUNDANT
On Sun, 5 Jan 2014 01:25:19 PM Chris Murphy wrote: Does the Ubuntu 12.03 LTS installer let you create sysroot on a Btrfs raid1 volume? I doubt it, given the alpha for 14.04 doesn't seem to have the concept yet. :-) https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1266200 All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: btrfs raid1 and btrfs raid10 arrays NOT REDUNDANT
On 07/01/14 06:25, Jim Salter wrote: FWIW, Ubuntu (and I presume Debian) will work just fine with a single / on btrfs, single or multi disk. I currently have two machines booting to a btrfs-raid10 / with no separate /boot, one booting to a btrfs single disk / with no /boot, and one booting to a btrfs-raid10 / with an ext4-on-mdraid1 /boot. Actually I've run into a problem with grub where a fresh install cannot boot from a btrfs /boot if your first partition is not 1MB aligned (sector 2048) then there is then not enough space for it to store its btrfs code. :-( https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1266195 I don't want to move my first partition as it's a Dell special (type 'de') and I'm not sure what the impact would be, so I just created an ext4 /boot and the install then worked. Regarding RAID, yes I realise it's easy to do post-fact, in fact on the same test system I added an external USB2 drive to the root filesystem and rebalanced as RAID-1, worked nicely. I'm planning on adding dual SSDs as my OS disks to my desktop and this experiment was to learn whether the Kubuntu installer handled it yet and if not to do a quick practice of setting it up by hand. :-) All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: btrfs raid1 and btrfs raid10 arrays NOT REDUNDANT
On Sat, 4 Jan 2014 02:56:39 PM Chris Mason wrote: Seconded +ADs-) We're really focused on nailing down these problems instead of hiding behind the experimental flag. I know we won't be perfect overnight, but it's time to focus on production workloads. Perhaps an option here is to remove the need to specify the degraded flag but if the filesystem notice that it is mounting a RAID array and would otherwise fail it then sets the degraded flag itself and carries on? That way the fact it was degraded would be visible in /proc/mounts and could be detected with health check scripts like NRPE for icinga/nagios. Looking at the code this would be in read_one_dev() in fs/btrfs/volumes.c ? All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: btrfs raid1 and btrfs raid10 arrays NOT REDUNDANT
On Sat, 4 Jan 2014 06:10:14 AM Duncan wrote: Btrfs remains under development and there are clear warnings about using it without backups one hasn't tested recovery from or are not otherwise prepared to actually use. It's stated in multiple locations on the wiki; it's stated on the kernel btrfs config option, and it's stated in mkfs.btrfs output when you create the filesystem. Actually the scary warnings are gone from the Kconfig file for what will be the 3.13 kernel. Removed by this commit: commit 4204617d142c0887e45fda2562cb5c58097b918e Author: David Sterba dste...@suse.cz Date: Wed Nov 20 14:32:34 2013 +0100 btrfs: update kconfig help text Reflect the current status. Portions of the text taken from the wiki pages. Signed-off-by: David Sterba dste...@suse.cz Signed-off-by: Chris Mason chris.ma...@fusionio.com -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: btrfs raid1 and btrfs raid10 arrays NOT REDUNDANT
On Sat, 4 Jan 2014 12:57:02 AM Dave wrote: I find myself annoyed by the constant disclaimers I read on this list, about the experimental status of Btrfs, but it's apparent that this hasn't sunk in for everyone. Btrfs will no longer marked as experimental in the kernel as of 3.13. Unless someone submits a patch to fix it first. :-) Can we also keep things polite here please. thanks, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: Unmountable Array After Drive Failure During Device Deletion
On Sun, 22 Dec 2013 11:35:53 AM Duncan wrote: While the btrfs kernel config option no longer (as of 3.12 IIRC) directly calls the filesystem unstable It'll be in 3.13, the commit was: $ git describe 4204617d142c0887e45fda2562cb5c58097b918e v3.12-116-g4204617 The help text for btrfs now says: Btrfs is a general purpose copy-on-write filesystem with extents, writable snapshotting, support for multiple devices and many more features focused on fault tolerance, repair and easy administration. The filesystem disk format is no longer unstable, and it's not expected to change unless there are strong reasons to do so. If there is a format change, file systems with a unchanged format will continue to be mountable and usable by newer kernels. For more information, please see the web pages at http://btrfs.wiki.kernel.org. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: moving a subvol
On Fri, 13 Dec 2013 02:25:34 PM Gene Czarcinski wrote: Next it is to delete the old BTRFS volume, use fdisk to increase the size of the partition and then attempt to increate the size of this new volume. I hope I don't get bit in the rear end with this. Just make sure you have good (tested) backups.. -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: [PATCH] Btrfs: fix a crash when running balance and defrag concurrently
On Wed, 30 Oct 2013 01:25:24 PM Liu Bo wrote: Running balance and defrag concurrently can end up with a crash: It's worth noting that Greg K-H has said he'll take stable patches before they hit mainline whilst Linus is off-net, as reported here at the kernel summit: https://lwn.net/Articles/571997/ # Greg added that, during this time, urgent stable fixes could, # contrary to normal policy, get into the stable tree prior to # being merged into the mainline; he won't hold them while # Linus is off the net. This patch seems like a very good candidate for that. cheers! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: 3.11.5 kernel infinite loop
On Wed, 6 Nov 2013 12:37:32 PM Duncan wrote: Note that there's another critical patch in-flight, patching a bug triggered by btrfs balance on filesystems with pre-allocated files (like systemd does with its journal and various torrent clients do with their downloads). But this one is currently being held up because stable rules require it to be in current mainline first, and 3.12 is out, but the two- week 3.13 commit window that would normally be open now is suspended for a week, as Linux is traveling without a reliable net connection. So the patch can't hit mainline, and thus won't hit stable unless an exception is made, until after Linus' vacation, when the commit window opens and the patch is accepted. Greg K-H has said he'll accept stable patches that haven't hit the mainline during this period. cheers! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: error count
On Sat, 10 Aug 2013 07:19:27 PM Russell Coker wrote:
But what does generation_errs mean? I'm seeing some on one system.
Should I be concerned? If I write a Nagios check which ones should be
warnings and which ones errors?
All I know is that ioctl.h says:
BTRFS_DEV_STAT_GENERATION_ERRS, /* an indication that blocks have not
* been written */
Looking at the kernel code that only seems to get incremented during a scrub.
The code that does that says:
} else if (generation != le64_to_cpu(h-generation)) {
sblock-header_error = 1;
sblock-generation_error = 1;
}
The generation there is from the btrfs inode structure, the header says:
/* full 64 bit generation number, struct vfs_inode doesn't have a big
* enough field for this.
*/
u64 generation;
The wiki says:
https://btrfs.wiki.kernel.org/index.php/Glossary
# generation
# An internal counter which updates for each transaction. When a
# metadata block is written (using copy on write), current generation
# is stored in the block, so that blocks which are too new (and hence
# possibly inconsistent) can be identified.
and:
https://btrfs.wiki.kernel.org/index.php/Btrfs_design
# Everything that points to a btree block also stores the generation
# field it expects that block to have. This allows Btrfs to detect
# phantom or misplaced writes on the media.
HTH!
Also why does it give the following errors about trying to open /dev/sr0
when using a BTRFS RAID-1 filesystem? Below is for a RAID-1 over /dev/sdb
and /dev/sdc.
I don't get that here, I'm building btrfs-progs from git at commit
194aa4a1bd6447bb545286d0bcb0b0be8204d79f (July 5th), aka:
btrfs-progs$ git describe --tags
v0.20-rc1-358-g194aa4a
cheers!
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP
signature.asc
Description: This is a digitally signed message part.
Re: btrfs device stats /dev/mapper/ext4 SEGV
On Sat, 10 Aug 2013 07:07:50 PM Russell Coker wrote: I can repeatedly get the following SEGV from running btrfs device stats on a device node for an Ext3/4 filesystem. This happens with the version of the code downloaded from the above GIT repository as well as with an older version. Obviously the command in question is not going to do anything useful when run against a non-BTRFS filesystem, but it should do something other than crash. The code calls btrfs_read_dev_super() on that filesystem, but it looks like the checks are failing to detect it as not btrfs. :-( I can reproduce the crash here too with ext3 and XFS filesystems. -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: performance loss with lots of snapshots
Hiya Russell, On 10/07/13 12:54, Russell Coker wrote: This has happened to me often enough that I can probably reproduce it on a VM. What kernel should I use for such tests? I'd suggest at least 3.10, and perhaps also Chris Mason's git tree here: https://git.kernel.org/cgit/linux/kernel/git/mason/linux-btrfs.git/ which is 3.10 plus the latest btrfs code that was merged by Linus into his master for 3.11 today. All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: Fwd: Current State of BTRFS
Hi Florian, On 10/02/13 00:35, Florian Hofmann wrote: (Sadly) No SSD. I think Marc was asking as they can cause issues, so don't be sad. :-) I just upgraded from kernel version 3.7.5 to 3.7.6 (running Arch Linux) with no change in behavior. There are rarely any updates to btrfs in stable kernel releases, if you want to try the current state of the code you'll need to try 3.8-rc7. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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 6/6] Btrfs-progs: detect if the disk we are formatting is a ssd
On 20/01/13 08:14, Brendan Hide wrote: Can't help but suggest that a NO_DEDUP command could be added to the SATA Transport Protocol/SCSI Command set. Not sure where to submit that idea ... :-/ Serial ATA International Organization (SATA-IO) maintain the specs for SATA. Looks like membership is limited to companies and costs US$1,700 a year. http://sata-io.org/ SCSI is from the T10 committee: http://www.t10.org/ The intro page indicates it's a fairly open group: # T10 operates under INCITS and is responsible for SCSI Storage # Interfaces. Its principal work is the Small Computer System # Interface (SCSI), including the family of SCSI-3 projects. # Anyone directly and materially affected is welcome to # participate on T10 (essentially, this amounts to anyone # interested in T10's work). cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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] [RFC v2] Btrfs: Subpagesize blocksize (WIP).
On 19/12/12 09:26, Wade Cline wrote: Yeah. Basically, if we create a btrfs filesystem with a 4k blocksize then that filesystem is incompatible with architectures such as PowerPC and MIPS which have a page size larger than 4k. What happens currently?Does the btrfs code detect the mismatch and refuse to mount, or does it all go horribly wrong? cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: Example of BTRFS uglyssima performance : Bitcoin
On 03/12/12 23:24, Swâmi Petaramesh wrote: I understand the suggestion from a developper's PoV, but from a user's that's much too much hassle living ahead of one's distro's kernel, or using vanilla ones. Been there, done that. No more suffering for me please ;-)) I'll have to stick with current Ubuntu kernel, or at least with a future backport... In that case maybe using an experimental filesystem that is under rapid development might not be a good choice, it might be better to stick to one of the existing stable filesystems instead. Have you benchmarked your workload on other filesystems? cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: [RESEND] btrfs corruption / cannot mount
Hiya Riccardo, On 02/12/12 19:49, Riccardo Berto wrote: I'm a btrfs user since I encountered the ext4 3.6.2 bug and then I decided to switch. You are aware that the ext4 issue you mention only affects people who turned on journal checksums, and is not turned on by default? This LWN article has a good summary: http://lwn.net/Articles/521803/ As Michael wrote btrfs is still considered an experimental filesystem. All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: [RFC PATCH] Btrfs-progs: disable qgroupid 0 for quota_tree
On 08/11/12 20:55, Miao Xie wrote: In kernel, qgroupid 0 is a special number when we run the quota group limit command. So, we should not be able to create a quota group whose id is 0, otherwise the kernel can't deal with it. Fix it. This is probably a stupid question - but if its not meant to be possible to create such a thing shouldn't this be fixed in the kernel (as well as here) to reject attempts from user space to create it? Otherwise it's possible for a non-aware program (or a user who is playing) to still create it. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: Crashes in extent_io.c after btrfs bad mapping eb notice
On 31/10/12 10:57, Franke wrote: I have been having some crashes like this. Since I upgraded to 3.6.4 they have become common. The crashes happen pretty randomly during normal system usage. After the syslog messages the system stays semi usable for a minute, but when I run any new program it hangs. I had to downgrade to 3.6.2 to get my system usable again. There were no btrfs changes in either 3.6.3 or 3.6.4, so it must be an interaction with another change - you will probably need to bisect between 3.6.2 and 3.6.3 to see what's causing it to happen. Worth noting that Greg K-H is looking for people to help him with the stable series... http://www.kroah.com/log/linux/minion-wanted.html cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: btrfs and mdadm raid 6
On 21/08/12 08:24, Curtis Jones wrote: You mentioned that btrfs was going to set aside a ton of space for metadata. Is that entirely due to going ext4 - btrfs? No, I believe that's a regression in btrfs in recent kernels.. -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: [GIT PULL 1/2] Btrfs fixes
On 10/08/12 01:50, Chris Mason wrote: Hi everyone, This first pull is the bulk of our changes for the next rc. It is against the 3.5 kernel so people testing the new features have a stable point to work against. This was tested against Linus' current tree as well. [...] This pull request with a whole heap of btrfs fixes (46 commits) appears not to have been merged yet, does anyone know if it was rejected or just missed ? cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: [GIT PULL 1/2] Btrfs fixes
On 21/08/12 11:55, Linus Torvalds wrote: Read my -rc2 release notes. Ahh, thanks (I'm not on LKML so didn't see those). TL;DR: I rejected big pull requests that didn't convince me. Make a damn good case for it, or send minimal fixes instead. Can't argue with that! I'm tried of these oops, what we sent you for -rc1 wasn't ready, so here's a thousand lines of changes crap. I can understand that with respect to the send/recv stuff, so it's really down to Chris Mason to extract just the fixes to problems that are in 3.5 and earlier and submit just those instead. All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: BUG on 3.5.0
On 08/10/2012 07:49 PM, Lluís Batlle i Rossell wrote: Am I right that it is not in 3.5.1? I don't believe fixes can be considered for stable releases until they're in the mainline, so until Linus processes that last merge request from Chris it can't happen (and he's not done so yet). That said, there was one btrfs fix merged into 3.5.1: Chris Mason (1): Btrfs: call the ordered free operation without any locks held But I suspect that is not the fix you are looking for.. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: severe hardlink bug
On 08/08/2012 04:37 PM, Konstantin Dmitriev wrote: Unfortunately I cannot afford to have unstable patched kernel on the production server. I'd suggest that using btrfs for production servers is probably a bit brave (no matter what Oracle say), and what you've found illustrates the point rather well I'm afraid.. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: kernel BUG at fs/btrfs/extent-tree.c:5038 (linux 3.4.7)
On 08/04/2012 08:41 AM, Olivier Bonvalet wrote: Is there something I can do to fix that ? (the mount option recovery didn't help here) I've seen someone (perhaps Marc Merlin) report that the 3.5.x kernel was able to mount a filesystem that 3.4.x couldn't, so it might be worth a shot here! Best of luck, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: no space left on device
Hi Mark, On 08/03/2012 08:05 PM, Mark Marshall wrote: I am new to btrfs, and just installed a new system with SLED 11 SP2 a few days ago. Looking at the release notes for SLED11 SP2 it appears to ship with an ancient kernel (in btrfs terms), 3.0.10. You will want to upgrade to *at least* a 3.2.x kernel (I use Kubuntu 12.04 on my work laptop with btrfs /home and had no issues with its 3.2.x), though it's likely you'll want to go straight to the current 3.5.x kernel. Best of luck! Chris -- 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: How can btrfs take 23sec to stat 23K files from an SSD?
On 01/08/12 16:01, Marc MERLIN wrote: Third, A freshly made ntfs filesystem through fuse is actually FASTER! Could it be that Samsungs FTL has optimisations in it for NTFS ? A horrible thought, but not impossible.. -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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/free-space-cache.c:1887 after hard shutdown.
On 29/06/12 15:36, Jordan Windsor wrote: I get the same problem with linux-mainline from AUR (latest) What does uname -a say ? cheers! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: ceph-on-btrfs inline-cow regression fix for 3.4.3
On 13/06/12 13:46, Alexandre Oliva wrote: I know btrfs hasn't had maintenance fixes in stable series, but Chris Mason tells me the only reason is that nobody stepped up to do so. Given my interest, I might as well give it a try ;-) Actually 3.3.3 had a fix for btrfs in it.. :-) http://lwn.net/Articles/493971/ cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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] Removing btrfsctl, btrfs-vol, btrfs-show
On Saturday 09 June 2012 16:24:19 Goffredo Baroncelli wrote: This commit removes all the related code. This doesn't seem to apply cleanly with patch (though git am seems to apply it OK) to the git repo master from: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git FYI patch complains thus: patching file INSTALL patching file Makefile patching file btrfs-show.c patching file btrfs-vol.c patching file btrfsctl.c patching file Makefile Hunk #1 FAILED at 6. Hunk #2 FAILED at 17. 2 out of 2 hunks FAILED -- saving rejects to file Makefile.rej patching file btrfs-image.8.in Hunk #1 FAILED at 31. 1 out of 1 hunk FAILED -- saving rejects to file btrfs-image.8.in.rej The next patch would delete the file btrfs-show.8.in, which does not exist! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored patching file btrfsck.8.in Hunk #1 FAILED at 14. 1 out of 1 hunk FAILED -- saving rejects to file btrfsck.8.in.rej The next patch would delete the file btrfsctl.8.in, which does not exist! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: Recovering a file from a snapshot without duplicating its blocks (--reflink across devs?)
On 05/06/12 13:01, Marc MERLIN wrote: First I though, I sure would be nice if I could take btrfs to reference the same blocks from the snapshot to my current image. But, --reflink failed across devices nodes, so I was forced to copy/duplicate the blocks (36GB). Patches for this were posted over a year ago, but it was NAK'd by Christoph Hellwig. I don't know if it's got any further since then. :-( Patch description: http://www.spinics.net/lists/linux-btrfs/msg09226.html NAK: http://www.spinics.net/lists/linux-btrfs/msg09229.html -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: Which kernel is safe to upgrade to for btrfs?
On 21/05/12 15:22, Marc MERLIN wrote: Have the free space problems been fixed in 3.3.x or is the 3.4.x branch better or should I stay with 3.2.x for safety? There have been some fixes pushed back from the development tree into the stable tree for 3.3.x (for the first time in btrfs's history I believe) but there's a lot more work been happening in 3.4. I'm happily sat on 3.2 and I would suggest sticking there too for a while and watch what user reports come back for the 3.4 kernel (just out). Just my 2p's worth.. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: btrfs tools typo
On Friday 11 May 2012 19:26:16 Andrei Popa wrote: In the latest btrfs tools from git it's a typo: I'll send a patch now. -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
[PATCH] Fix set-dafault typo in cmds-subvolume.c
Andrei Popa reported that there were two typos of default as dafault,
this patch fixes those two typos up.
Signed-off-by: Chris Samuel ch...@csamuel.org
---
cmds-subvolume.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmds-subvolume.c b/cmds-subvolume.c
index 950fa8f..23c72b4 100644
--- a/cmds-subvolume.c
+++ b/cmds-subvolume.c
@@ -394,7 +394,7 @@ static int cmd_snapshot(int argc, char **argv)
}
static const char * const cmd_subvol_get_default_usage[] = {
- btrfs subvolume get-dafault path,
+ btrfs subvolume get-default path,
Get the default subvolume of a filesystem,
NULL
};
@@ -432,7 +432,7 @@ static int cmd_subvol_get_default(int argc, char **argv)
}
static const char * const cmd_subvol_set_default_usage[] = {
- btrfs subvolume set-dafault subvolid path,
+ btrfs subvolume set-default subvolid path,
Set the default subvolume of a filesystem,
NULL
};
--
1.7.4.1
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP
signature.asc
Description: This is a digitally signed message part.
Re: btrfs and 1 billion small files
On 07/05/12 20:06, Boyd Waters wrote: Use a directory hierarchy. Even if the filesystem handles a flat structure effectively, userspace programs will choke on tens of thousands of files in a single directory. For example 'ls' will try to lexically sort its output (very slowly) unless given the command-line option not to do so. In my experience it's not so much that lexical sorting that kills you but the default -F option which gets set for users these days, that results in ls doing an lstat() on every file to work out if it's an executable, directory, symlink, etc to modify how it displays it to you. For instance on one of our HPC systems here we've a user with over 200,000 files in one directory. It takes about 4 seconds for \ls whereas \ls -F takes, well I can't tell you because it was still running after 53 minutes (strace confirmed it was still lstat()ing) when I killed it.. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: Can btrfs silently repair read-error in raid1
On 08/05/12 17:13, Clemens Eisserer wrote: Would it be possible to create 2 btrfs partitions on that drive and use it in RAID1 - with btrfs silently repairing read-errors when they occur? You can, I tried that in 2009: http://www.csamuel.org/2009/01/04/btrfs-raid1-benchmark-on-dell-e4200-with-128gb-ssd But as Chris Mason pointed out on list at that time, it doesn't necessarily mean you're any safer due to the way that FTL's work: http://permalink.gmane.org/gmane.comp.file-systems.btrfs/2575 cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: An issue when mounting the dd-copied partition and the original one together
On Friday 20 April 2012 16:49:48 Tydus Ken wrote: I guess there's something wrong with btrfs in how to deal with two partition with same UUID or something else, but I'm not sure. I don't believe that btrfs can cope with partitions with the same UID. A pointer here from Auke in July 2011: http://marc.info/?l=linux-btrfsm=131161949201880w=2 # Resetting the UUID on btrfs isn't a quick-and-easy thing - you # have to walk the entire tree and change every object. We've got # a bad-hack in meego that uses btrfs-debug-tree and changes the # UUID while it runs the entire tree, but it's ugly as hell. # # You shouldn't clone btrfs really, just make a new filesystem. That hack is for an unmounted filesystem, but I don't believe it's been shared on this list. Jan Schmidt was working on a btrfs send type command to help with this, but I've not heard anything recently (last December he posted that he was distracted by the backref-walking code which was a necessary precursor for the send/receive code). cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: [PATCH] btrfs: don't return EINTR
On 18/04/12 05:43, Arne Jansen wrote: but not even the manpage states EINTR as return value from unlink. Yeah, it's not mentioned in the Single UNIX Spec: http://pubs.opengroup.org/onlinepubs/9699919799/functions/unlink.html -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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 00/19 v5] Fix filesystem freezing deadlocks
On 17/04/12 15:10, Andreas Dilger wrote:
(which IMHO would prevent nearly every Gnome system from freezing unless these
apps have changed their behaviour in more recent releases).
It would also affect current KDE desktops as they tend to use MySQL for
Akonadi Nepomuk, plus anyone using Chromium (and presumably Chrome):
samuel@eris:/tmp$ sudo lsof | grep deleted | awk '{print $1}' | sort |
uniq -c
[sudo] password for samuel:
32 chromium-
1 dovecot
5 imap-logi
5 mysqld
I would be surprised if you could find many systems that didn't have
files in this situation.
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
--
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: btr fs unmountable after disk failure
On Friday 13 April 2012 20:58:22 Hugo Mills wrote: I think you need -o degraded in this case. I've always wondered why btrfs doesn't fall back to this by default if it fails to find a device, would seem the obvious thing to do (we don't have to tell mdadm if a disk has gone away for instance). cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: btrfs: open_ctree failed
On 27/03/12 09:47, Hugo Mills wrote: I'd definitely recommend running as recent a kernel as you can -- either the last released (3.3 in this case) I'm not sure I'd recommend 3.3; there were a number of reports of a regression regarding preamture ENOSPC in that code which was bisected to a particular change but I didn't see any evidence of it being fixed in 3.3 (only 2 unrelated fixes were merged after rc6, where this problem was confirmed). https://lkml.org/lkml/2012/3/9/624 I'm currently running 3.2.13 from the Ubuntu site here: http://kernel.ubuntu.com/~kernel-ppa/mainline/ I just download the deb via Lynx and install it with dpkg -i $PACKAGE. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: heterogeneous raid1
On Saturday 24 March 2012 04:35:39 Bob McElrath wrote: I'm still dreaming of a fs/admin tool that I can throw disks at, and not have to spend so much time with the details of partitioning/raid/lvm/fs. There was a tool called System Storage Manager (ssm) that someone from RedHat posted about late last year: http://www.redhat.com/archives/linux-lvm/2011-December/msg00012.html Unfortunately it looks like the git repo on SourceForge hasn't been touched since the code was pushed last December. :-( cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: [RFC PATCH 0/5] apply rwlock for extent state
On 21/03/12 23:34, Andrea Gelmini wrote: No comment, but I'm using this patches without problem since you published it (compressed /home with hourly snapshot delete/creation). Well worth sending a Tested-By: tag then, it's useful information. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: scrub stops the machine
On Monday 19 March 2012 19:22:58 Martin Steigerwald wrote: Maybe 3.2.10 oder 3.2.11 contains some related fixes? I don't believe that any btrfs fixes get pushed to the stable releases (at least, not yet), you'll need 3.3 for newer code. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: scrub stops the machine
On Sunday 18 March 2012 19:04:00 Helmut Hullen wrote: Second try with kernel 3.2.5: same problem. My understanding is that all 3.2.x versions will have the same btrfs code, if you want to try with a newer version you'll need to try the 3.3 release candidates. cheers! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: not enough space with data raid0
On Saturday 17 March 2012 23:01:00 Helmut Hullen wrote: Where is the problem, how can I use the full space? Which kernel was this with Helmut? cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: btrfs oops (autodefrag related?)
On Tuesday 13 March 2012 11:04:35 Chris Mason wrote: This one was fixed in the 3.3 series. You can pull from my for-linus repo for a commit against 3.2. Note though that some people are reporting regressions with premature ENOSPC in 3.3-rc7, to quote: # - bisected down to 5500cdb (Btrfs: increase the global block # reserve estimates). After reverting this one Linus master works # for me again. Though after reversion they hit ENOSPC much later (but still prematurely). cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: immutable (WORM) file system
On Tuesday 13 March 2012 10:40:39 David Sterba wrote: (I just know that the flag is there and is related to the question, haven't tested it myself and do not know what was the original intention.) Not sure it helps, but the commits for these were: commit fdebe2bd70047e057827cba85ba31b2545e31900 Author: Yan yanzh...@21cn.com Date: Mon Jan 14 13:26:08 2008 -0500 Btrfs: Add readonly inode flag This patch adds readonly inode flag support. A file with this flag can't be modified, but can be deleted. Signed-off-by: Chris Mason chris.ma...@oracle.com and.. commit cb6db4e57632ba8589cc2f9fe1d0aa9116b87ab8 Author: Jeff Mahoney je...@suse.de Date: Mon Aug 15 17:27:21 2011 + Author: Jeff Mahoney je...@suse.de Date: Mon Aug 15 17:27:21 2011 + btrfs: btrfs_permission's RO check shouldn't apply to device nodes This patch tightens the read-only access checks in btrfs_permission to match the constraints in inode_permission. Currently, even though the device node itself will be unmodified, read-write access to device nodes is denied to when the device node resides on a read-only subvolume or a is a file that has been marked read-only by the btrfs conversion utility. With this patch applied, the check only affects regular files, directories, and symlinks. It also restructures the code a bit so that we don't duplicate the MAY_WRITE check for both tests. Signed-off-by: Jeff Mahoney je...@suse.com Signed-off-by: Chris Mason chris.ma...@oracle.com -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: btrfs oops (autodefrag related?)
Forgot citations, sorry! On Tuesday 13 March 2012 11:13:28 Chris Samuel wrote: Note though that some people are reporting regressions with premature ENOSPC in 3.3-rc7, to quote: # - bisected down to 5500cdb (Btrfs: increase the global block # reserve estimates). After reverting this one Linus master works # for me again. is from https://lkml.org/lkml/2012/3/9/624 Though after reversion they hit ENOSPC much later (but still prematurely). is from https://lkml.org/lkml/2012/3/12/231 -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: kernel BUG at fs/btrfs/delayed-inode.c:1466!
On 09/03/12 12:31, Liu Bo wrote: So are these warnings based on the latest upstream of btrfs? Looks like it was 3.2.7, his oops said: Pid: 1488, comm: mips-wrs-linux- Tainted: GW3.2.7 #2 HP -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: filesystem full when it's not? out of inodes? huh?
On Sunday 26 February 2012 19:52:06 Duncan wrote: It's astonishing to me the number of people that come in here complaining about problems with a filesystem the kernel option of which says Title: Btrfs filesystem (EXPERIMENTAL) Unstable disk format On the other hand, if they didn't keep complaining then perhaps that label would go away prematurely because nobody was reporting problems? :-) cheers! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: btrfs open_ctree failed (after recent Ubuntu update)
Hi Curtis, On Sunday 19 February 2012 13:47:35 Curtis Jones wrote: I don't want to push this too far in the direction of being an Ubuntu support thread; but do you happen to know of any convenient methods for installing a 3.2.x kernel on Ubuntu? I'd like to minimize the chance of screwing up my existing Ubuntu installation My suggestion would be (given the uname -a info you supplied showed you were running a PAE kernel): 1) First become root with: sudo -i 2) Then download the current stable mainline kernel release: wget -c http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2.6-precise/linux-image-3.2.6-030206-generic- pae_3.2.6-030206.201202131435_i386.deb 3) Install the deb package you just downloaded with: dpkg -i ./linux-image-3.2.6-030206-generic-pae_3.2.6-030206.201202131435_i386.deb Then you should be able to reboot into it. If you want to get rid of it you reboot and pick the latest 3.0 kernel that grub offers you and then: sudo -i apt-get remove --purge linux-image-3.2.6-030206-generic-pae Hope this helps! cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: btrfs open_ctree failed (after recent Ubuntu update)
On Sunday 19 February 2012 07:34:22 Curtis Jones wrote: Any help would be appreciated. Thank you. Please CC me on any replies. Linux veriton 3.0.0-16-generic-pae #28-Ubuntu SMP Fri Jan 27 19:24:01 UTC 2012 i686 i686 i386 GNU/Linux That's a fairly old kernel in btrfs terms, you may want to try the latest 3.2.x kernel from the Ubuntu Mainline Kernel PPA here: http://kernel.ubuntu.com/~kernel-ppa/mainline/ If that doesn't work out you can try the latest 3.3 RC there too. I'm running the 64-bit 3.2.5 kernel from there on Kubuntu 11.10 and it is fine (modulo boot time complaints about the apparmour stuff). cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: brtfs on top of dmcrypt with SSD. No corruption iff write cache off?
On Monday 13 February 2012 11:14:00 Marc MERLIN wrote: I knew that it created some security problems but I had not yet found the page you just gave, which effectively states that TRIM isn't actually that big a win on recent SSDs (I thought it was actually pretty important to use it on them until now). In addition TRIM has always been problematic for SATA SSD's as it was initially specified as a non-queueable command: https://lwn.net/Articles/347511/ However, it appears that a queueable TRIM command has been introduced for SATA 3.1: http://techreport.com/discussions.x/21311 cheers! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: Several unhappy btrfs's after RAID meltdown
On Tuesday 07 February 2012 20:53:59 Duncan wrote: Kernel 3.2.2 is relatively recent altho you could try the latest 3.3 rc or git kernel as well Please keep in mind that work done in git does not appear to get backported to the stable updates for releases (such as 3.2.x), in other words you'll have the same btrfs code as in the first 3.2 release. You will need to use RC's (or git) for the current btrfs kernel code. Particularly when it's used on top of a dmcrypt layer that btrfs was known to have issues with I believe the issues between btrfs and dm-crypt have been sorted out as of 3.2 (going on an earlier posting of Chris Masons). Returning to the OP's case, I'm surprised that ext4 is able to get anything back and I'd say that's a testament to its long development life (ext-ext2-ext3-ext4) in comparison to btrfs. If that happened on a system I was sysadmin'ing (and it has - losing an entire tray of drives in a RAID array due to controller firmware bugs really spoils your day) I'd be reaching for the backup tapes about now. Best of luck! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: Btrfs out of inodes becomes corrupt
On Monday 06 February 2012 06:57:42 Hugo Mills wrote: This al under debian with kernel 2.6.32-5. Aargh. You are aware that this is an insanely old version of the brtfs code, and it has major flaws in it? As someone who runs his work laptop with a 2.6.32 laptop and btrfs for /home I'll bite at this one - I've held off updating after reading the issues people were reporting on the list with newer kernels that did not appear to be present in 2.6.32 (indeed IIRC a particular problem from that time could only be solved at the time be remounting the filesystem with 2.6.32, at which point newer kernels could access it again). It's served me very well, it just works (so far at least). It's now sounding that 3.2 is probably stable enough for me to consider updating to the next KUbuntu release when it comes out. NB: Yes, I do make nightly backups, and no, I don't run the filesystem at anything close to even a quarter full (not that that guarantees anything, or is even particularly deliberate). cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: Errors after clean reboot
On Thursday 19 January 2012 17:54:37 Elsa Thomas wrote: I can no longer mount my Btrfs filesystem after a clean reboot. Before the reboot, there were errors in the syslog, but unfortunately I can't recover them now that the root filesystem won't mount. Might be worth trying to remount read-only, I've seen others reporting success with that when it won't remount read-write. Best of luck! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
