Re: LFS thoughts

[Thor Lancelot Simon <tls%panix.com@localhost>]

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.

-- 
Thor Lancelot Simon	                                     tls%panix.com@localhost
  "The liberties...lose much of their value whenever those who have greater
   private means are permitted to use their advantages to control the course
   of public debate."					-John Rawls