On Mon, Apr 11, 2016 at 5:32 AM, Austin S. Hemmelgarn <ahferroin7@xxxxxxxxx> wrote: > On 2016-04-09 03:24, Duncan wrote: >> >> Yauhen Kharuzhy posted on Fri, 08 Apr 2016 22:53:00 +0300 as excerpted: >> >>> On Fri, Apr 08, 2016 at 03:23:28PM -0400, Austin S. Hemmelgarn wrote: >>>> >>>> >>>> I would personally suggest adding a per-filesystem node in sysfs to >>>> handle both 2 and 5. Having it open tells BTRFS to not automatically >>>> attempt countermeasures when degraded, select/epoll on it will return >>>> when state changes, reads will return (at minimum): what devices >>>> comprise the FS, per disk state (is it working, failed, missing, a >>>> hot-spare, etc), and what effective redundancy we have (how many >>>> devices we can lose and still be mountable, so 1 for raid1, raid10, and >>>> raid5, 2 for raid6, and 0 for raid0/single/dup, possibly higher for >>>> n-way replication (n-1), n-order parity (n), or erasure coding). This >>>> would make it trivial to write a daemon to monitor the filesystem, >>>> react when something happens, and handle all the policy decisions. >>> >>> >>> Hm, good proposal. Personally I tried to use uevents for this but they >>> cause locking troubles, and I didn't continue this attempt. >> >> >> Except that... in sysfs (unlike proc) there's a rather strictly enforced >> rule of one property per file. > > Good point, I had forgotten about this. I just ran across this: https://www.kernel.org/doc/Documentation/block/stat.txt Q. Why are there multiple statistics in a single file? Doesn't sysfs normally contain a single value per file? A. By having a single file, the kernel can guarantee that the statistics represent a consistent snapshot of the state of the device. So there might be an exception. I'm using a zram device as a sprout for a Btrfs seed. And this is what I'm seeing: [root@f23m 0]# cat /sys/block/zram0/stat 64258 0 514064 19 19949 0 159592 214 0 233 233 Anyway there might be a plausible exception, if there's a good reason, for the one property per file rule. -- Chris Murphy -- 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
