Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have a bunch of servers connected to a SAN. One server hosts the production database server, performing full database backups to a filesystem on a LUN that is exported to all servers.

Only the "owner" (production server) has this filesystem mounted read-write. When the owner has performed a full backup, sync is called.

The other hosts later mount this filesystem read-only, for quick access to the backup, for loading copies. This way I don't have the network as a bottleneck for transferring the backup.

I have had this setup on Solaris for ages, with no glitches, on a plain UFS filesystem.

Now I am going to set up the same on Linux (RHEL6), and want advice on what filesystem to pick. I'm thinking simpler is better, because I absolutely don't want any other host than the owner to make any changes whatsoever. No journal replay or other crazy stuff that can confuse the owners kernel if the on-disk structures stop matching what the kernel "knows" is there.

I hope you understand my question. I've seen stuff happen (like journal replay) when mounting read-only filesystems on linux that worry me a bit.

I'm looking for something simple. Not a cluster filesystem that requires handshaking and heartbeats. Only one node needs to write.

share|improve this question
add comment

2 Answers

up vote 1 down vote accepted

According to the linux man-page for mount, you can use "-o ro,noload" for an ext3/ext4-filesystem (which would be my choice of FS for this).

share|improve this answer
add comment

I think you've been very lucky not to run into problems with this before.

Certainly, any number of boxes should be able to read from most filesystems as read-only without problems. And you can prevent all write (including journal replays) by setting the device as read-only (e.g. using blockdev).

But what do you think would happen on your current architecture if the writing host decided to fsck the filesystem while it was still mounted elsewhere?

If it were me I think a better approach might be to move a disk between two RAID1 sets to migrate the data across/use the snapshot facility in the SAN. Or just go with a network file system or a cluster filesystem.

share|improve this answer
    
All the activity on the shared device occurs at fixed times. The other hosts don't need to have it mounted except when reading. The writing host never "decides" to fsck the filesystem on its own. (Only at boot after unclean umount, which makes it an academic-only issue on this system). Forced to think about it: the less important systems might panic, if they have cached something and attempt to read. Forgot to mention that we make a fresh mount prior to each reading session. –  MattBianco Nov 16 '11 at 12:29
    
do you have a specific cluster filesystem in mind? This is one "small" system in an enterprise. It happens daily, no problems so far (10+ years). I can't schedule things on the SAN (and think its inappropriate). NFS is too slow and the network guys frown upon wasting their capacity. (Terabytes read daily). –  MattBianco Nov 16 '11 at 12:36
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.