[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OT: Comparison of filesystems



On Thu, Apr 27, 2006 at 05:58:52PM -0500, Mike McCarty wrote:
> Digby Tarvin wrote:
 
[snip]
 
> >I do try to keep as many of my filesystems as possible mounted read-only
> >(ideally everything but /var and /home) so I suppose I could have cron
> >run a regular fsck.
> 
> This also makes some sense, though not quite so much. Especially
> on your laptop :-)

True - my laptop is certainly getting plenty of 'boot' action at the
moment.

However if I manage to get the suspend/resume working reliably
when I get around to testing it, then it might be a different story ;)

To be more specific about what I do on my '24/7' server, my procedure
is as follows:

When I need to modify something outside of /home or /var I do a
	mount -o remount,rw
and do what I need to do.

The nightly backup script then finds it is r/w, makes it r/o and
makes a backup.

Here's a sample of what is in the script:
   ######### /usr/local #######
   #
   if mount|grep " /usr/local"|grep -q "read-only" ;then
           echo "/usr/local is read-only, no backup required"
   else
           echo "Backing up /usr/local"
           /sbin/mount -u -o ro /usr/local
           /sbin/mount -u -o rw /backup/local
           /usr/local/bin/rsync -avH /usr/local/ /backup/local
           /sbin/mount -u -o ro /backup/local
   fi

My thought was that it might be prudent to fsck the dirty filesystem
before using it to overwrite the backup.

> >P.S. to include something relevent to the original thread, I have
> >use both Reiserfs and Ext3, and have never found enough performance
> >or reliability difference to worry about - so for me the main
> >advantges of each are:
> >  ext3     - more complere set of tools, such as dump/restore
> 
> IMO, this is the single most important issue with any
> of these file systems. They are all good it seems. But the
> additional support varies widely.

I agree. I have opted for ext3 on my Debian system for that very
reason.

Although I have recently encountered a bug with dump/restore on
Debian Etch, which seems to fail on filesystems containing more
than 2147483647 bytes of data (ie too big for a signed 32 bit int),
and a 2G limit on filesystem size is getting pretty restrictive on
modern hardware.

I need to install from the original source to see if it is a
Debian packaging/build problem...

Regards,
DigbyT
-- 
Digby R. S. Tarvin                                          digbyt(at)digbyt.com
http://www.digbyt.com



Reply to: