On Tue, Aug 11, 2015 at 2:26 PM, Timothy Normand Miller <theo...@gmail.com> wrote: > On Tue, Aug 11, 2015 at 3:47 PM, Chris Murphy <li...@colorremedies.com> wrote: > >> >> Huh. I thought nodatacow applies to an entire volume only, not per >> subvolume unless you use chattr +C (in which case it can be per >> subvolume, directory or per file). I could be confused, but I think >> you have mutually exclusive mount options. > > Well, at the time I set up this system, I asked on IRC, and people > said it should work. I've never seen any errors from this.
Error implies a mistake with some sort of reference. All Btrfs does is inform you of conflicting options: [ 8.766903] BTRFS info (device sdc): setting nodatacow, compression disabled Unfortunately that message should not reference just one device but a volume label or UUID in my opinion. When I test manual mount of subvolume first with -o compress, followed by mount of another subvolume with -o nodatacow, this is the results from mount: /dev/sdb on /var/mnt/root type btrfs (rw,relatime,seclabel,compress=zlib,space_cache) /dev/sdb on /var/mnt/home type btrfs (rw,relatime,seclabel,compress=zlib,space_cache) When I do -o nodatacow first, followed by -o compress /dev/sdb on /var/mnt/root type btrfs (rw,relatime,seclabel,nodatasum,nodatacow,space_cache) /dev/sdb on /var/mnt/home type btrfs (rw,relatime,seclabel,nodatasum,nodatacow,space_cache) The compress is ignored, and it looks like nodatasum and nodatacow apply to everything. The nodatasum means no raid1 self-healing is possible for any data on the entire volume. Metadata checksumming is still enabled. >>> [94312.091613] BTRFS info (device sdc): allowing degraded mounts >>> [94312.091618] BTRFS info (device sdc): disk space caching is enabled >>> [94312.194513] BTRFS: bdev (null) errs: wr 1724, rd 305, flush 45, >>> corrupt 0, gen 2 >>> [94319.824563] BTRFS: checking UUID tree >> >> I don't see any mount failure message. It worked then? > > Yes and no. It's mounted, but a scrub aborts silently: > > # btrfs scrub status /mnt/btrfs/ > scrub status for ecdff84d-b4a2-4286-a1c1-cd7e5396901c > scrub started at Tue Aug 11 13:56:36 2015 and was aborted after 01:31:55 > total bytes scrubbed: 2.19TiB with 0 errors > > No new messages appeared in dmesg, so I can't tell why it aborted. > It's also odd that it reports zero errors, given that it aborted. Well I wouldn't expect a scrub to completely work in this, even though it probably should fail more gracefully than this: a.) you don't have a complete array I don't know what a scrub of a degraded volume even means b.) the data has no checksums so the only thing that can really be scrubbed is metadata So I'd say there are three UI/UX bugs here: a.) The info message about nodatacow overriding compression should refer to label and/or UUID not device. b.) When degraded, a scrub should give more meaningful information on the scope of what can and can't be done; or at the least say scrub isn't possible on degraded volumes. c.) When nodatacow, scrub should scrub metadata and inform user metadata is scrubbed but data can't be scrubbed due to nodatacow. -- Chris Murphy -- 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
