Re: unhooking lfs from ufs
Perhaps not a very meaningful voice, but I think it makes sense to split them. Johnny David Holland wrote: On Mon, Feb 08, 2010 at 11:03:44AM +0900, Masao Uebayashi wrote: This thread? http://mail-index.netbsd.org/tech-kern/2009/07/21/msg005526.html That was later - that's about what happens to quotas afterwards. But I can't find the original thread, which as I recall was moderately lengthy, so maybe it wasn't on tech-kern? Anyway, I want to hear the rest of what eeh@ has to say, which means I'm not going ahead tonight, which means nothing will be happening for a few days at least anyhow. So if anyone wants to object or hash through this in detail now, go right ahead.
Re: unhooking lfs from ufs
Hmmm... Eduardo Horvath wrote: On Sun, 7 Feb 2010, David Holland wrote: Anyhow, it seems to me that isolating it from changes to ffs is likely to result in less breakage over time, not more. Can you expand on your reasoning some? The most significant parts that are shared are the directory ops and the read/write routeines. The directory ops are essentially FFS code with an LFS wrapper around it. Right now any ffs bugfixes for those used directly by LFS. The read/write routines also share about 80% of the code. I suppose there is a better case for separating these out if it makes code maintenance easier. If we were to separate them out then every time someone fixes a problem with FFS, the same changes would be required to be made for LFS. Historically this has not happened. When you look at UVM or UBC integration, there were long periods of time when LFS was unusable because that filesystem has been considered of secondary importance. So, the fact that the code was shared did indeed *not* make FFS fixes also flow over into LFS? (I assume that FFS was fixed for those things in short order.) That would, in my eyes, mean that this argument isn't valid. LFS has a rather small user base since it's historically been considered experimental and most machines can't boot from it. Few people use it and fewer still work on it. Indeed. I tried LFS a few times many years ago, but had some problems with it, along with the experimenal status of it, which made me stop trying. I would love to hear someone allay my fears, but I think segregating the LFS code from the FFS code will accelerate the bitrot and the final result will be removal of the LFS code. I can't alleviate your fears, however, it appears to me that the assumption that LFS benefits from sharing code with FFS is wrong, or atleast exaggerated. Looking at how the LFS code have had problems for extended periods, even with shared code with FFS suggests that LFS have not really gained much from that sharing. Having the code split, and then possibly getting it leaner and cleaner, looks like a potential gain atleast. Johnny
Re: unhooking lfs from ufs
On Mon, 8 Feb 2010, Adam Hamsik wrote: On Feb,Monday 8 2010, at 9:33 PM, Eduardo Horvath wrote: On Mon, 8 Feb 2010, Adam Hamsik wrote: Are you sure that you can really finish this ? Currently you are working on namei, ufs_lookup and many other issues. Make LFS not compilable is the way to make it disappear very soon. I think that these changes should happen in separate branch and should be committed back to main branch only when it will be at least compilable again. s/compilable/reasonably solid/ I'll be rather upset if my lfs partitions suddenly stop working. LFS is not solid for a long time, now. The only problems I've been having with it resently are media errors. Eduardo
Re: unhooking lfs from ufs
On Feb,Monday 8 2010, at 10:37 PM, Eduardo Horvath wrote: On Mon, 8 Feb 2010, Adam Hamsik wrote: On Feb,Monday 8 2010, at 9:33 PM, Eduardo Horvath wrote: On Mon, 8 Feb 2010, Adam Hamsik wrote: Are you sure that you can really finish this ? Currently you are working on namei, ufs_lookup and many other issues. Make LFS not compilable is the way to make it disappear very soon. I think that these changes should happen in separate branch and should be committed back to main branch only when it will be at least compilable again. s/compilable/reasonably solid/ I'll be rather upset if my lfs partitions suddenly stop working. LFS is not solid for a long time, now. The only problems I've been having with it resently are media errors. What version of NetBSD are you using ? LFS is known to be broken after vmlocking2 merge, because it heavily depended on kernel big lock model used before. Regards Adam.
unhooking lfs from ufs
On several occasions it's been suggested that lfs should be unhooked from ufs, on the grounds that sharing ufs between both ffs and lfs has made all three entities (but particularly lfs) gross. ffs and lfs are not similar enough structurally for this sharing to really be a good design. Nobody I've discussed this with (on the lists or in chat) has been opposed, and I think there's a general consensus that this is the right direction. Getting there, however, is going to perhaps be a bit more controversial. Since ufs does provide a lot of functionality to lfs, it seems to me that the only practical way to do this is to cut and paste a copy of ufs into lfs under a different name, hack it up so it works again, and then begin consolidating. Anything else would involve either cutting off far too much work at once or leaving lfs entirely inoperable (as opposed to merely unstable) for a lengthy period; both of these propositions seem like a worse idea than attending to and merging changes into a chunk of copied code. (In fact, I've been maintaining and syncing the copy since July, and it's not been a big deal so far.) So I think this is the best approach. The copy involves 18 files from sys/ufs/ufs (out of 21; the ones excluded are quota.h and unsurprisingly ufs_wapbl.[ch]) which contain 9067 lines of code. That gives the following statistics: 14988 size of lfs currently + 9067 size of copypasted ufs 24055 size of resulting uncompilable lfs - 401 result of making it compilable 23654 size of new lfs This is the size of the code in sys/ufs/lfs; the userlevel tools need patching but don't change size significantly. My guess/estimate is that after several rounds of consolidation the total size will drop to around 18000-19000 lines. Maybe less, even, but I wouldn't count on that. I'll be keeping an eye on the total size going forward. Anyway, I have done this much and it's ready to go. I will be committing it tonight, I think, unless there are sudden howls of protest. The diff (from HEAD of a couple hours ago to the new compilable lfs) is posted here: http://www.eecs.harvard.edu/~dholland/netbsd/lfs-ufs-20100207.diff I will probably commit the pasted-only uncompilable form first, and maybe some of the intermediate steps as well, for the historical record and to make future merges easier. This may make the tree temporarily unbuildable, but hopefully not for very long. -- David A. Holland dholl...@netbsd.org
Re: unhooking lfs from ufs
David Holland dholland-t...@netbsd.org wrote: The copy involves 18 files from sys/ufs/ufs (out of 21; the ones excluded are quota.h and unsurprisingly ufs_wapbl.[ch]) which contain 9067 lines of code. That gives the following statistics: 14988size of lfs currently + 9067size of copypasted ufs 24055size of resulting uncompilable lfs - 401result of making it compilable 23654size of new lfs How would this affect UFS side? For example, any potential code reduction and/or simplification? Anyway, I have done this much and it's ready to go. I will be committing it tonight, I think, unless there are sudden howls of protest. This involves significant changes, therefore enough time should be left for mailing list readers (~1 week at least, before committing anything). -- Mindaugas
Re: unhooking lfs from ufs
On Sun, Feb 07, 2010 at 10:10:31AM +, Mindaugas Rasiukevicius wrote: The copy involves 18 files from sys/ufs/ufs (out of 21; the ones excluded are quota.h and unsurprisingly ufs_wapbl.[ch]) which contain 9067 lines of code. That gives the following statistics: 14988 size of lfs currently + 9067 size of copypasted ufs 24055 size of resulting uncompilable lfs - 401 result of making it compilable 23654 size of new lfs How would this affect UFS side? For example, any potential code reduction and/or simplification? Yes. ufs_readwrite.c will become much less gross, for example. There used to be assorted LFS-only code in the ufs sources; ad@ removed the ifdefs some time ago but they could be resurrected and then used to purge the relevant code. I don't know how much code that is. As for deeper simplifications, I don't know without digging around a lot more than I have (particularly in the ext2fs code), but there should be some. Anyway, I have done this much and it's ready to go. I will be committing it tonight, I think, unless there are sudden howls of protest. This involves significant changes, therefore enough time should be left for mailing list readers (~1 week at least, before committing anything). It was discussed months ago. This is a reminder/heads-up. -- David A. Holland dholl...@netbsd.org
Re: unhooking lfs from ufs
David Holland dholland-curr...@netbsd.org wrote: How would this affect UFS side? For example, any potential code reduction and/or simplification? Yes. ufs_readwrite.c will become much less gross, for example. There used to be assorted LFS-only code in the ufs sources; ad@ removed the ifdefs some time ago but they could be resurrected and then used to purge the relevant code. I don't know how much code that is. As for deeper simplifications, I don't know without digging around a lot more than I have (particularly in the ext2fs code), but there should be some. Good, I think it would be great to look into this. This involves significant changes, therefore enough time should be left for mailing list readers (~1 week at least, before committing anything). It was discussed months ago. This is a reminder/heads-up. Where? This mailing list is a right place where such discussions (and decisions) should happen. -- Mindaugas
Re: unhooking lfs from ufs
On Sun, Feb 07, 2010 at 11:07:55AM +, Mindaugas Rasiukevicius wrote: It was discussed months ago. This is a reminder/heads-up. Where? This mailing list is a right place where such discussions (and decisions) should happen. Right here... -- David A. Holland dholl...@netbsd.org
