On 2016-04-17 20:55, Chris Murphy wrote:
On Mon, Apr 11, 2016 at 5:32 AM, Austin S. Hemmelgarn
<ahferro...@gmail.com> 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.
Part of the requirement for that though is that we have to provide a
consistent set of info. IOW, we would probably need to use something
like RCU or locks to handle the data so we could get a consistent
snapshot of the state.
--
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
