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

[Dustin Schwacke]

The method I would recomend in a psudo-embeded environment(minimal 
system access for shutdown) would be the following configuration.

Kernel and non-dynamic file systems loaded via ramdisk into a ramfs or 
memory.

Reguarding logs and dynamic files, there are 2 questions, size of the 
file system and number of files.
If the filesystem is very large or you have lots of small files and are 
also concerned about power on times, then you want to look towords 
reiserfs ( some have clamed that reiserfs is prone to data corruption. 
The only times i have ever seen any reiserfs filesystems get corrupted 
was due to failing memory or processors and no filesystem can prevent 
that)  as it has the quickest rebuild time. If you have a smaller 
filesystem and fewer but larger files, then ext3fs is the way to go. 
since the data is important, you want to stay away from ext2 or non 
journaling filesystems.
Once you have determined the filesystem, then you need to look at 
mounting option. You want to set non buffering or caching settings so 
that all actons will be writen to disk immediately, in case of power 
failure or hardware issues.

I am sure I am missing something and it will come to me seconds after 
hitting the send button, but I hope this helps

dragon<at>atlantacon<dot>org

Christopher Fowler wrote:

>On Mon, 2005-07-11 at 17:44 -0400, Claudia Morlan wrote:
>  
>
>>Thank you for the ideas.
>>
>>Currently, the encrypted partition (/dev/hda7) is not in fstab.  It is
>>loaded via a script that gets the encryption key and then unencrypts the
>>/dev/loop0 to a mount point.  We will put everything but this encrypted
>>partition in RO mode on bootup.  (thanks for that idea).  We'll also see
>>about running fsck on every boot.  We can't really lose the data once it
>>is
>>stored on the device.  About re-wiring the power supply, it's not
>>possible
>>(at least with our abilities) to make it become a soft-off switch.
>>(think
>>old AT computers type PS/controller).
>>
>>    
>>
>
>You can do what others do.  Have an internal battery that will provide
>enough power to shut down the device.
>
>  
>
>>Thanks.
>>----- Original Message -----
>>From: "Christopher Fowler" <cfowler at outpostsentinel.com>
>>To: "Atlanta Linux Enthusiasts" <ale at ale.org>
>>Sent: Monday, July 11, 2005 5:05 PM
>>Subject: Re: [ale] Best FS to use when doing unclean shutdowns?
>>
>>
>>    
>>
>>>On Mon, 2005-07-11 at 17:00 -0400, James P. Kinney III wrote:
>>>      
>>>
>>>>Ah, HA! A basic dumb kiosk box.
>>>>
>>>>Make the basic boot section RO (/, /boot, /bin, /sbin). Make the
>>>>        
>>>>
>>/var
>>    
>>
>>>>a
>>>>skeleton that gets populated by a rc.local script.
>>>>
>>>>Put the data collection part on a separate partition. Change the
>>>>        
>>>>
>>boot
>>    
>>
>>>>scripts so it is NOT automatically loaded. Force a file-system auto-
>>>>repair check on every boot before mounting. Use EXT3 (easy to
>>>>        
>>>>
>>install
>>    
>>
>>>>from RedHat and derivatives) or ReiserFS (Mandrake and SUSE) (Debian
>>>>and
>>>>Slackware come with both). Use hdparm to setup no write buffering on
>>>>the
>>>>partition. Use a cron job that runs every minute to perform a "sync"
>>>>to
>>>>keep everything flushed.
>>>>
>>>>Use a second cron job to keep a mirror of the "live" partition as a
>>>>backup. In the event the fsck fails for any reason, use the backup
>>>>partition to overwrite it with.
>>>>
>>>>Rewire the power switch to only perform a soft-off, controlled power
>>>>down and reset.
>>>>
>>>>        
>>>>
>>>I like this idea.  You can also reformat the FS storage if it gets
>>>beyond repair.  It all depends on how valuable the data is.  If the
>>>reason for HDD is because there is so much data but losing it is not a
>>>problem then you could reformat on failure to clean and mount.
>>>      
>>>
>>
>>Visit us at the 28th Annual BAI Retail 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
>>    
>>
>
>_______________________________________________
>Ale mailing list
>Ale at ale.org
>http://www.ale.org/mailman/listinfo/ale
>
>
>
>  
>