Date:        Sun, 30 Jan 2000 12:24:32 -0800
    From:        Jonathan Stone <jonathan@DSG.Stanford.EDU>
    Message-ID:  <200001302032.MAA11579@Greyhawk.DSG.Stanford.EDU>

  | isn't the Right Thing really to allow
  | the kernel to update its incore superblock and write that to disk?

Absolutely.

There was a time in BSD's history when the super blocks actually
lived in the buffer cache (just locked so they could not be reused
for other purposes) - that way any write to the super block location
on the drive (via the block device) just updated the super block as a
side effect.

Then the buffer cache was reorganised one more time, and this broke...

I would think that now with UVM it ought be fairly easy to fix this
again (and without returning the super block to the buffer cache).
There already needs to be something to handle consistency between
mapped files and buf cached files (right ... I hope) - that ought to
be able to be extended to cope with the super blocks as well - even
if that means treating super blocks as if they were mmap'd regions in
some process's address space (like process 0's perhaps).   Maybe they
could even be implemented that way.   Of course I haven't looked at
the UVM code at all, so perhaps what I am suggesting is too hard.

kre