SLUG Mailing List Archives
Re: [SLUG] : Increasing filesystem reliability (was : Filesystem which allows online fsck?)
- To: Erik de Castro Lopo <mle+slug@xxxxxxxxxxxxx>
- Subject: Re: [SLUG] : Increasing filesystem reliability (was : Filesystem which allows online fsck?)
- From: Glen Turner <gdt@xxxxxxxxx>
- Date: Thu, 12 Jun 2008 16:30:05 +0930
- Cc: slug@xxxxxxxxxxx
- User-agent: Thunderbird 126.96.36.199 (X11/20080501)
Erik de Castro Lopo wrote:
Does anyone have anything else to suggest?
mount ext3 with options:
Create the fs with a bigger journal than usual, this will
improve performance with journal=data.
Our scientists often forgo filesystems entirely if the
application is simple (eg, data collection). For example,
they'll zero the partition at the start. To record an
observation they'll seek to a position based on the time
(or observation number reported by the data hardware)
and sync write the fixed-length observation with a checksum.
Note that Linux's performance with sync-ing is poor on a
multi-use machine (since all buffers are synced, not just
the application's buffers).
Note that barrier=1 won't work with LVM or DM, you need
a real partition.
You might want to consider a distro like OpenWrt which
minimises the amount of incidental disk I/O done by
the distribution and allows a definite split between
a read-only partition and a read-write partition. The
the amount of read-write disk to be recovered will be
smaller (since read-only partitions don't need recovery).