Remy Blank posted on Fri, 09 Jan 2015 12:19:23 +0100 as excerpted: > I have a btrfs filesystem that shows the following errors. This happens > either when writing to the FS or when snapshotting, I'm not sure (this > FS holds my backup, and I write to it with rsync and snapshot > afterward). > > Jan 8 13:54:33 twin kernel: BTRFS error (device dm-2): > error inheriting props for ino 3828 (root 317): -28 > Jan 8 13:54:38 twin kernel: BTRFS error (device dm-2): > error inheriting props for ino 17939 (root 317): -28 Just another user here, posting only to say I don't recall seeing a props inheritance error like that posted before. Could be a new and interesting bug. Also, when you post errors, please post kernel and btrfs-progs versions. I see from the trace that your kernel version is 3.17.7 so you're reasonably current there, but of course that doesn't give the userspace version. And finally just a practical note. Over time I've noticed that rsync seems to be involved in quite a few posted bugs, most of which have of course been fixed by now. Rsync apparently stresses btrfs in ways few other tasks do, thus triggering more than its share of bugs that most other things don't tend to tickle. I'm a gentooer myself, with (among other things) the main package tree rsynced to btrfs, and have seemed to escape these issues, but (1) all my btrfs are on SSD and thus likely escape some of the race conditions that trigger on spinning rust, and (2) I'm a strong believer in not putting all my data eggs in the same filesystem basket so I partition heavily, and all my partitions are relatively small (biggest btrfs 24 GiB, actually the gentoo tree, sources, and binpkgs partition). Additionally, I prefer backups to identically sized partitions over snapshots (which are nice but if the filesystem has problems it takes all the snapshots with it), and thus don't tend to use the btrfs snapshots feature. I suspect that has something to do with my relative scarcity of triggered btrfs issues, here. So just be aware that rsync /does/ seem to stress btrfs more than most tasks, and try to plan/behave accordingly, perhaps avoiding rsync when possible, or keeping additional backups in case, and/or choosing something other than btrfs for at least one level of backups, etc. (FWIW my non-btrfs level of backups here is reiserfs, the filesystem I used for years previously, which at least since the introduction of data=ordered back around kernel 2.6.16 or so, has done very well for me even thru hardware issues, etc. Others on the list recommend xfs, but few seem particularly impressed with ext*, for whatever it's worth. That last could simply be a biased sample, tho, as people involved in btrfs are I suspect less likely to be content with the traditional ext* status quo than the average Linuxer, but whatever the reason, cause or bias, ext* seems to get short shrift on this list.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
