On Fri, 22 Oct 2004 08:30:49 +0000, Zafer Aydogan wrote:

> Hej Alex,
> 
> LFS is not ready for production use, as far as I can form an opinion about
> that. It seems to be quite stable, but produces Errors, as soon as you pass
> 70% of the disk size; sometimes. (More or less, which depends)

I have all the data which are not precious (kernel compilation
directories, objdirs and pkgsrc tree) on LFS. No problems so far.

Having such often-written data on LFS has at least 3 advantages:

1) LFS is faster on writes

2) it has some sort of journaling, and moving as much data as possible
from the non-journaling fs to a journaling one will probably reduce fsck
time.

3) As the data on the non-journaling fs are mainly read-only, there is
lower risk that those filesystem will get damaged, because more data
written means more risk.

Also, I have filled the LFS up to 89% I believe and had no problems. Maybe
it depends not on the percentage but on the absoulute amount of unused
space.

What kind of "Errors" did you experience?

>> I am wondering if LFS can be considered ready for production use in 2.0
>> (for values of 2.0 = building at least weekly from the release branch).
>> I have a hardware RAID that will be under heavy NFS and Samba load, and
>> I'm tempted to use LFS (this is all happening on i386, BTW). I've

I'm afraid I have heard that NFS on LFS is very slow for some reason.

>> searched in the regular places, and have not been able to find
>> information later than about 1.6.1, at which point the opinions were
>> fairly ambivalent. Should I abandon the vain desire to always have the
>> Latest and Greatest and just stick with FFS+softdeps?

Maybe use async mode instead of softdeps? I saw no in-depth explanation
why it should be unsafe. Also people tell that async was always used in
Linux until ext3fs etc. were introduced, and I never had problems with it.

One my experience with async mode was that after some crash or power
failure or hard reset, fsck complained about some completely harmless
error - such as inode of a recently deleted file being deleted, while the
directory entry wasn't, and fsck wanted to be run manually. Probably fsck
assumes that the filesystem is mounted in the default(noasync) or softdeps
mode and if it finds errors which can't appear in such modes, it
complains, even if the errors are harmless, which is a bit disappointing.

Conclusion: don't use async mode if you don't have console access to the
machine to run fsck manually. Otherwise it should be fine IMHO.

Bye	Pavel