lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 29 May 2013 01:42:30 +0000 (UTC) From: Duncan <1i5t5.duncan@....net> To: linux-kernel@...r.kernel.org Cc: linux-btrfs@...r.kernel.org Subject: Re: [RFC PATCH v1 0/5] BTRFS hot relocation support Kent Overstreet posted on Tue, 28 May 2013 17:38:15 -0700 as excerpted: > On Tue, May 21, 2013 at 02:22:34AM +0000, Duncan wrote: >> zwu.kernel posted on Mon, 20 May 2013 23:11:22 +0800 as excerpted: >> >> > The patchset is trying to introduce hot relocation support for BTRFS. >> >> One advantage of a filesystem implementation, as opposed to bcache or >> dmcache, is arguably a corner-case, but it's /my/ corner-case, so... >> >> I run an intr*-less (I guess technically, empty initramfs) monolithic- >> kernel boot [so] any user-space-required-to- mount-root is out [...] >> >> Much like md before it, btrfs, while normally requiring the user-space- >> required device-scan to properly handle multiple devices, has kernel- >> command-line options that allow direct kernel multi-device assembly >> without the help of early-userspace/initr*. Just a note that while btrfs is /supposed/ to have that functionality, I'm actually trying to make it work now, and failing (I can get it to work only with rootflags=degraded, which then of course screws the sync between the devices, losing the point of multi-device mirroring). As (about a year ago when I brought it up then) someone else (btrfs dev) mentioned not being able to get rootflags=dev=... to work on the kernel command line with btrfs as well, I assume that functionality is broken due to some as yet un-addressed bug, hopefully to be fixed by the time btrfs is finally declared stable. However, that exchange from a year ago suggests it's not a particularly high priority... Meanwhile, I'm working on switching to a very minimal (dracut-based but cut WAY down) initramfs now. Basically only enough to mount the btrfs multi-device raid1 mirror since the kernel commandline rootflags method appears to be broken, but still with a monolithic kernel, etc, so REALLY quite minimal, indeed. (Once I get the semi-automated dracut host-only no-kernel with most-default-modules-omitted version working to give me a base pattern to work with, I may well switch to a hand assembled and kernel-built initramfs, trimming it down even further.) Hopefully someday the btrfs or rootflags kernel command-line bug will be fixed and I can go initr*less again. So in terms of bcache, for me personally for now, I could in theory add it to the minimal initr*. But there's certainly others running initr*- less as well, and I'd prefer to be in that class myself once again at some point. (When gentoo devs suggested forcing initr* for the separate / usr case, users raised QUITE a ruckus, so initr*less may be a minority case, but there's still quite a few out there, systemd's universe- engulfing gray-goo to the contrary or not.) So there's certainly people out there running initr*less who could make use of some sort of hot-data-cache-device functionality, if it's available to them. > I wouldn't be averse to adding such functionality to bcache, provided it > could be done reasonably cleanly/sensibly. It's not high on my list but > I'd accept patches :) Unfortunately I'm more an admin type than coder. I know my way around a Linux system well enough to confidently troubleshoot and trace bugs, but for anything other than shell-script, only in the trivial case can I actually file an appropriate bugfix patch and feature-patching is right out. So unfortunately, while I'm interested, such a patch can't come from me. =:^( But should anyone else with interest AND the ability be reading... =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists