>>>>> "re" == Robert Elz <kre%munnari.OZ.AU@localhost> writes: re> might have been if we were talking about adding LFS to NetBSD, re> but that was done years ago, the question now is whether to re> remove it, not whether to add it. since it's broken, it's really whether to keep it, remove it, or leave it in but broken. You're laying out choices as if ``let's keep it'' required 0 work and made 0 problems except the allegation something else might be faster. Since it doesn't work right now, that's not the case. And most of my post was about the huge gap between ``seems to work enough to be excited about'' and ``works well enough to actually use''---with filesystems, more than half the work comes after the excitement, and LFS has never even crossed that hump. The real no-action choice is to leave it nominally, meaninglessly in, but broken. Broken as it has been all along, it's just more broken now. re> The worst scenario is for someone who upgrades then finds that re> their LFS filesystems no longer work I've no doubt someone will pipe up and say, ``omg! omghai! yes I have an LFS! scurry around and do all this work so I don't have to find blank space and use pax.'' But AIUI it never worked well enough that any reasonable person could rely on it for permanent storage, and this is not the first time LFS has worked less well in a newer formal release than in an older one. re> I'd submit that NetBSD 5 needs to include, at the very least, re> a read-only safe LFS implementation please, NO, do not connect the already glacial release of NetBSD 5 containing the critical-to-survival thread fixes to the demand for a stable LFS, which has been unmet for over a decade. saying ``oh, but it can be a from-scratch read-only implementation!''---is that supposed to make it EASIER?! What's more, you don't use it yourself. I _have_ used it. At this stage, let the person who wants to hold up the 5.0 release by insisting someone else fix LFS for him, let that person speak up, so I can disagree with him. strawmen are bad enough, but pandering to straw men is ridiculously bashful. re> (that it has more or less always been listed as experimental re> provides some excuse for simply dropping it, but not really re> enough). how about that it's always performed as experimental: worked better and worse from one release to the next, caused lots of panics and borkenness and lost data, never shipped with a reliable lfsck? Its obvious behavior should make a stronger warning than the note in the man page. There is obviously a limited amount of interest to work with. I think it's silly for people not interested in doing the work to argue about what others should do, and that's what I was doing, so I should stop. But saying ``5.0 cannot be released without working LFS'' is even *worse* than what I'm doing, which is saying, ``having some workable filesystem for >1TB volumes, like the multiple options Linux and FreeBSD have and the single option Solaris has, is more important than preserving the ability to read experimental datasets written by broken code in old versions of NetBSD.'' Whether you want to ``keep'' LFS or not, in terms of typing 'cvs delete' or not (which makes no direct irrevocable difference), or more meaningfully, keep talking about it or not, or more realistically, keep encouraging people to work on it by saying ``no we don't want to start importing ZFS/HAMMER/whatever because we already have LFS which is almost working and much better'' (which is the standard NetBSD way of encouraging people to work on something), all that ASIDE, binding working LFS to 5.0 release is worse than all those things, is a disastrously bad idea because you will frustrate the release and end up with only minimally-working toy LFS at best.
Description: PGP signature