Re: LFS thoughts

[Brad Spencer <brad%anduin.eldar.org@localhost>]

Thor Lancelot Simon <tls%panix.com@localhost> writes:

> On Fri, Aug 22, 2025 at 06:09:31PM -0700, Konrad Schroder wrote:
>> 
>> There has been quite a lot of work on LFS in the last 20 years, some with
>> hints of a roadmap.?? Does anyone else have specific ideas about the most
>> glaring issues, or what should be done next?
>
> I have been looking at the original Sprite LFS code (still available for
> download, with a reasonable license) and wondering if many of the design
> decisions made in rewriting it for 4.4BSD were actually as valid as CSRG
> thought.  I think the largest architectural changes could be summarized as:
>
> * Move the cleaner out of the kernel (I have long thought this was a bad
>   idea for security reasons, and it sounds like you have concluded it is
>   also a bad idea for concurrency/correctness reasons)
>
> * Move inodes and the ifile "into the log" instead of just keeping them
>   at the front of the disk.  It sounds like you are now concluding this
>   decision was bad too, at least as originally implemented.
>
> * Share various on-disk and in-memory structures with the FFS code.  We
>   now have lots of filesystems that don't, so I'm not sure how much of
>   an advantage this is, really, and I think there are ways it complicates
>   FFS, not for the better.
>
> This leaves me wondering whether, given the scope and complexity of what
> it sounds like you're thinking of diving into to fix BSD LFS some more,
> and the likelihood of breaking backwards compatibility with older BSD LFS
> filesystems, it might make more sense to start over with the code from
> Sprite.


I have tried to make use of LFS over the years without any success.  The
last attempt was with a 9.x pkgsrc build environment where WRKOBJDIR
pointed to a LFS filesystem.  This would have probably been on a amd64
system type, but might have been a earmv6hf or earmv7hf environment
(don't remember).  Although it was better then in the past, the
environment hung up pretty quickly.  When it functioned, it was quite
fast, and made a good WRKOBJDIR destination in that respect, but wasn't
at all stable.

Has anyone actually tried to use (and I mean that it the non trivial
sense) LFS lately and actually had it not lock the system up??






-- 
Brad Spencer - brad%anduin.eldar.org@localhost