On Jan 3, 2014, at 7:59 PM, Jim Salter <j...@jrs-s.net> wrote: > > On 01/03/2014 07:27 PM, Chris Murphy wrote: >> This is the wrong way to solve this. /etc/grub.d/10_linux is subject to >> being replaced on updates. It is not recommended it be edited, same as for >> grub.cfg. The correct way is as I already stated, which is to edit the >> GRUB_CMDLINE_LINUX= line in /etc/default/grub. > Fair enough - though since I already have to monkey-patch 00_header, I kind > of already have an eye on grub.d so it doesn't seem as onerous as it > otherwise would. There is definitely a lot of work that needs to be done on > the boot sequence for btrfs IMO.
Most of this work is done for a while in current versions of GRUB 2.00. There are a few fixes due in 2.02. There are some logical challenges making snapshots bootable in a coherent way. But a major advantage of Btrfs is that functionality is contained in one place so once the kernel is booted things usually just work, so I'm not sure what else you're referring to? >> I think it's bad advice to recommend always persistently mounting a good >> volume with this option. There's a reason why degraded is not the default >> mount option, and why there isn't yet automatic degraded mount >> functionality. That fstab contains other errors. > What other errors does it contain? Aside from adding the "degraded" option, > that's a bone-stock fstab entry from an Ubuntu Server installation. fs_passno is 1 which doesn't apply to Btrfs. >> You're simply dissatisfied with the state of Btrfs development and are >> suggesting bad hacks as a work around. That's my argument. Again, if your >> use case requires automatic degraded mounts, use a technology that's mature >> and well tested for that use case. Don't expect a lot of sympathy if these >> bad hacks cause you problems later. > You're suggesting the wrong alternatives here (mdraid, LVM, etc) - they don't > provide the features that I need or are accustomed to (true snapshots, copy > on write, self-correcting redundant arrays, and on down the line). Well actually LVM thinp does have fast snapshots without requiring preallocation, and uses COW. I'm not sure what you mean by self-correcting, but if the drive reports a read error md, lvm, and Btrfs raid1+ all will get missing data from mirror/parity reconstruction, and write corrected data back to the bad sector. All offer scrubbing (except Btrfs raid5/6). If you mean an independent means of verifying data via checksumming, true you're looking at Btrfs, ZFS, or PI. > If you're going to shoo me off, the correct way to do it is to wave me in the > direction of ZFS There's no shooing, I'm just making observations. 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
