Peter Hardy wrote:
On Tue, 2010-02-02 at 22:07 +1100, david wrote:
Does fstab allow for two UUID's having the same mount point thus:
UUID=2e7c5578-933a-4b09-a89d-14b6be718fe5 /mnt/BACKUP ext4 defaults 0 0
UUID=b007bc41-0280-48d5-b958-9160092e3d44 /mnt/BACKUP ext4 defaults 0 0
Yes. Have you tried it yet? :-)
I have now. I'm getting erratic and unsatisfying results. Mostly it
fails to mount. Always mounts on reboot. I can mount manually, so maybe
since I always have to be there to put the hardware in, that's the
solution. I'm not about to deliberately mount them both, so that one
remains to be seen ;-)
var/log/messages says:
Feb 3 22:41:52 david kernel: [37287.337301] sd 3:0:0:0: [sdb] Attached
SCSI disk
Feb 3 22:42:39 david kernel: [37335.105748] EXT4-fs (sdb1): barriers
enabled
Feb 3 22:42:39 david kernel: [37335.118484] kjournald2 starting: pid
19625, dev sdb1:8, commit interval 5 seconds
Feb 3 22:42:39 david kernel: [37335.118762] EXT4-fs (sdb1): internal
journal on sdb1:8
Feb 3 22:42:39 david kernel: [37335.118768] EXT4-fs (sdb1): delayed
allocation enabled
Feb 3 22:42:39 david kernel: [37335.118772] EXT4-fs: file extents enabled
Feb 3 22:42:39 david kernel: [37335.184901] EXT4-fs: mballoc enabled
Feb 3 22:42:39 david kernel: [37335.184911] EXT4-fs (sdb1): mounted
filesystem with ordered data mode
but the disk is not mounted.
I thought that these disks would mount like a USB stick.
Especially given that this machine has three caddies on board, so it's
theoretically possible for me to accidentally mount both backup drives
simultaneously! Would I be so silly? it's at least possible.
Does anyone know what happens if they both successfully mount?
Anecdote time!
One of the sites I look after runs a large proprietary application
server, and the customer's installed SOE uses a /tmp partition far too
small for the installation / upgrade process utilised by said
application server. The installer also has this wonderful bug wherein it
ignores all attempts to define a new temporary file location. My process
for applying hotfixes to the app server includes:
Create a large empty file under /var/tmp .
Create a filesystem in this file.
Mount it over the existing /tmp using the loopback driver.
Run the upgrade.
Unmount the temporary /tmp .
Say you have the first filesystem mounted on /mnt/BACKUP , and some
processes have open file handles on that first filesystem. Mounting a
second filesystem over /mnt/BACKUP will not interrupt those open file
handles - all reading and writing using those handles will still use the
first filesystem. I *think* that new file handles opened by those old
processes will use the second filesystem (including readdir() calls and
the like), but I haven't tested this too thoroughly.
New processes attempting to read from /mnt/BACKUP will only see the
second filesystem mounted there.
Listing the mounted filesystems with the mount command will show two
filesystems mounted on /mnt/BACKUP . I have no idea what will happen
when you just run umount /mnt/BACKUP, and would suggest being more
explicit about which filesystem you want to unmount.
Bottom line, though, is that you won't break anything by experimenting
with this. If you're nervous, make sure you have a backup of the
filesystems you're playing with, or create a couple of loopback ones to
test with.
Also, I can't wait until the end of this month, when those app servers
are retired...
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
