> Now, before we go off and design YABFS, can we just get real for > a second ?
I leave it to others to design YAFS, I just wanted to complain about this one :-) Every few years I seriously look at speeding up fsck but give up. I remember even asking about it a few years ago on one of these groups. > I have been tending UNIX computers of all sorts for many years and > there is one bit of wisdom that has yet to fail me: > > Every now and then, boot in single-user and run full fsck > on all filesystems. > > If this had failed to be productive, I would have given up the > habit years ago, but it is still a good idea it seems. Even now I use fsck in forground since the background fsck was not stable enough the last time I used it. But I remember thinking fsck was taking too long for as long as I have used it (since 1981). > Personally, I think background-fsck is close to the ideal situation > since I can skip the "boot in single-user" part of the above > profylactic. Anything that runs for half hour or more in fg is likely to take longer in bg. What happens if the system crashes again before it finishes? Will bg fsck handle that? Am I right in thinking that it can not save files in /lost+found? In general I am very uneasy with bg fsck -- when I am validating something I don't want to be creating new stuff. > If you start to implement any sort of journaling (that is what you > talked about in your email), you might as well just stop right at > the "clean" bit, and avoid the complexity. No, I didn't suggest journaling, I suggested storing all state in a contiguous area (or a small number of such areas). indirect blocks, keeping track of free blocks, etc. You can still do a completely exhaustive fsck but it won't be exhausting to you. Journaling is also a good idea:-) > Optimizing fsck is a valid project, I just wish it would be somebody > who would also finish the last 30% who would do it. I am skeptical you will get more than a factor of 2 improvement without changing the FS (but hey, that is 3 hours for Julian so I am sure he will be happy with that!). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
