[ale] Best FS to use when doing unclean shutdowns?

[Dow Hurst]

I've read most all the posts on this thread and wanted to make sure one 
point was clear.  A journaling filesystem does not guarantee data won't 
be lost.  It only guarantees that the file system integrity will stay 
intact after a hard shutdown without sync.  I think the posts that 
pointed out the filesystem mount options that force the write to 
complete without caching data is very important to your application.

An aside, XFS and Reiserfs have robust tools for checking and fscking a 
filesystem with problems the same as ext2fs and ext3fs.  You should make 
sure that your filesystem is checked on reboot whichever filesystem you 
choose.  I prefer Reiserfs now over XFS since it is better for lots of 
small files with the default settings.  XFS is great for very large file 
systems, large files, and robust power management of the system since it 
aggressively caches data.  I've never had a problem with Reiserfs or XFS 
in production that wasn't fixable by the tools unless hardware was 
involved.  I've definitely had the same experience with ext2fs and 
ext3fs.  Ext3fs has some unique options such as being mountable as 
ext2fs if needed.
Thanks,
Dow


Claudia Morlan wrote:
>Hello all,
>
>We are trying to setup a system that will need to be hard shutdown when
>it's
>deployment time is over (~1-3weeks).
>It may be rebooted during this time as well via the power button.
>
>What is the best FS to use for this type of scenario?  There will not be
>any
>KVM attached to this device.  Also, we are planning on at least 1
>partition
>to be encrypted on this machinve as well.  Currently it is using Ext2
>and
>doesn't seem to have had a problem yet with hard shutdowns/etc.
>
>Thanks,
>Claudia
>
>
>
>Visit us at the 28th Annual BAI Retial Delivery Conference & Expo, November 15-18, 2005 - Orlando FL!
>
>
>This email and any files transmitted with it are solely intended for the use of the
>addressee(s) and may contain information that is confidential and privileged. If 
>you receive this email in error, please advise us by return email immediately. 
>Please also disregard the contents of the email, delete it and destroy any copies 
>immediately. 
>
>_______________________________________________
>Ale mailing list
>Ale at ale.org
>http://www.ale.org/mailman/listinfo/ale
>
>