On Fri, Feb 10, 2017 at 4:34 PM, John Hendy <jw.hendy@xxxxxxxxx> wrote: > > I did a couple of things after I sent this. For one, I ditched > arch/root. Now I just have arch. That let me get away from the call to > a nested subvol. > > That on it's own didn't work, but I started playing with the > rootflags. I haven't tried one by one, but re-specifying my mount > options seems to work. So instead of just rootflags=subvol=arch, I > have: > > rootflags=compress=lzo,subvol=arch,ssd,discard > > Is there a reason that would make a difference? The only change that should matter is subvol path change, and I'm not even convinced of that. But I don't even know where exactly the failure is. It sounds like the failure happens right away and you get back to the syslinux menu; that suggests to me the kernel isn't even loaded let alone executed, and the boot parameters don't matter until the kernel is executed. > I started wondering > about the compression immediately and I admit I'm not savvy on how > that works. Not a factor for two reasons: a. Your boot volume is not Btrfs, so the fact syslinux (actually extlinux in this case) doesn't support compression doesn't matter. Its job is just to load and execute the kernel and initrams. b. The file system metadata contains information per extent whether it's compressed and with which algorithm. So Btrfs doesn't need the compression hint as a boot parameter either. This mount option is only needed to tell the kernel to write new extents with compression. -- 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
