If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
do your harddisk have an onboard cache? do you care about your data?
then you need barriers.
xfs and reiserfs care about data, so they turn it on by default
extX devs don't care about your data, so they turn it off by default
do your harddisk have an onboard cache? do you care about your data?
then you need barriers.
xfs and reiserfs care about data, so they turn it on by default
extX devs don't care about your data, so they turn it off by default (argued with '30% performance loss')
jfs doesn't have barrier support at all from all I could find.
So, from time to time, the raid system will check (tunefs could avoid this, but for safety reasons we perform the complete disk check) the data. This needs hours where you just can wait and wait ....
So, if ext4 would reduce this checking time, i would immediatley change.
lvcheck (http://www.redhat.com/archives/linux.../msg00088.html) allows background checks to be performed on ext3 volumes on an LVM system (using snapshots). If the checks reveal that the filesystem is healthy, its last check date is updated; this avoids unscheduled fscks on boot. This can be done say at night during weekends (depending on your backup schedule of course ). The script also works with XFS and JFS, but I haven't used it on these so I daren't comment on the specifics.
The only downside is that orphaned inodes are not cleared, so scheduled fscks are still useful from time to time.
Leave a comment: