Rich Freeman posted on Fri, 24 Feb 2012 13:47:45 -0500 as excerpted: > On Fri, Feb 24, 2012 at 1:43 PM, Alexis Ballier <aball...@gentoo.org> > wrote: >> moreover the && wont delete the lib if revdep-rebuild failed i think, >> so it should be even safer to copy/paste :)
FWIW this is the preserved_libs feature/bug I ran into in early testing, that convinced me to turn it off. Running revdep-rebuild manually was far safer anyway, since at least then I /knew/ the status of various libs, they weren't preserved on first run, then arbitrarily deleted on second, even if it still broke remaining depending apps to do so. So if that was reliably fixed, I'd be FAR happier about enabling FEATURES=preserved-libs. I'm not sure I actually would as I like a bit more direct knowledge of stale libs on the system than the automated handling gives me, but at least I'd not have to worry about the so-called "preserved" libs STILL disappearing and leaving broken packages, if I DID enable it! So definitely ++ on this! =:^) > Am I the only paranoid person who moves them rather than unlinking them? > Oh, if only btrfs were stable... FWIW, in the rare event it breaks revdep-rebuild or the underlying rebuilding itself, I rely on my long set FEATURES=buildpkg and emerge -K. In the even rarer event that too is broken, there's always manual untarring of the missing lib from the binpkg (I've had to do that once when gcc itself was broken due to an unadvised emerge -C that I knew might break things given the depclean warning, but also knew I could fix with an untar if it came to it, which it did), or if it comes to it, booting to backup and using ROOT= to emerge -K back to the working system. [btrfs status discussion, skip if uninterested.] I'm not sure if that's a reference to the btrfs snapshots allowing rollbacks feature, or a hint that you're running it and worried about its stability underneath you... If it's the latter, you probably already know this, but if it's the former, and for others interested... I recently set the btrfs kernel options and merged btrfs-progs, then read up on the wiki and joined the btrfs list, with the plan being to get familiar with it and perhaps install it. >From all the reports about it being an option for various distros, etc, now, and all the constant improvement reports, I had /thought/ that the biggest issue for stability was the lack of an error-correcting (not just detecting) fsck.btrfs, and that the restore tool announced late last year, that allows pulling data off of unmountable btrfs volumes was a reasonable workaround. What I found, even allowing for the fact that such lists get the bad reports and not the good ones, thus paint a rather worse picture of the situation than actually exists for most users, is that... BTRFS still has a rather longer way to go than I had thought. It's still FAR from stable, even for someone like myself that often runs betas and was prepared to keep (and use, if necessary) TESTED backups, etc. Maybe by Q4 this year, but also very possibly not until next year. I'd definitely NOT recommend that anyone run it now, unless you are SPECIFICALLY running it for testing and bug reporting purposes with "garbage" data (IOW, data that you're NOT depending on, at the btrfs level, at all) that you are not only PREPARED to lose, but EXPECT to lose, perhaps repeatedly, during your testing. IOW, there's still known untraced and unfixed active data corruption bugs remaining. Don't put your data on btrfs at this point unless you EXPECT to have it corrupted, and want to actively help in tracing and patching the problems! Additionally, for anyone who has been interested in the btrfs RAID capacities, striped/raid0 it handles, but its raid1 and raid10 capacities are misnamed. At present, it's strictly two-way-mirror ONLY, there's no way to do N-way (N>2) mirroring aside from layering on top of say mdraid, at all, and of course layering on top of mdraid loses the data integrity guarantees at that level, btrfs still has just the one additional copy it can fall back on. This SERIOUSLY limits btrfs data integrity possibilities in a 2+ drive failure scenario. btrfs raid5/6 isn't available yet, but the current roadmap says kernels 3.4 or 3.5. Multi-mirror is supposed to be built on that code, tho the mentions of it I've seen are specifically triple-mirror, so it's unclear whether arbitrary N-way (N>3) mirroring as in true raid1 will be possible even then. But whether triple-way specifically or N-way (N>=3), given it's on top of raid5/6, to be introduced in 3.4/3.5, triple-way mirroring thus appears to be 3.5/3.6 at the earliest. So while I had gotten the picture that btrfs was stabilizing and it was mostly over-cautiousness keeping that experimental label around, that's definitely NOT the case. Nobody should really plan on /relying/ on it, even with backups, until at least late this year, and very possibly looking at 2013 now. So btrfs is still a ways out. =:^( Meanwhile, for anyone that's still interested in it at this point, note that the homepage wiki currently listed the btrfs-progs package is a stale copy on kernel.org, still read-only after the kernel.org breakin. The "temporary" but looking more and more permanent location is: http://btrfs.ipv5.de/index.php?title=Main_Page Also, regarding the gentoo btrfs-progs package, see my recently filed: https://bugs.gentoo.org/show_bug.cgi?id=405519 -- 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
