OTHER NOTES FROM LINUX USERS
From David C 4/30/2010:
Good news! I successfully got the sata_sil24 driver in Debian "Lenny" 5.0 (2.6.26) to notice multiple drives on the same enclosure. Here's what you should tell people:
The sata_sil24 driver does properly handle port multipliers; it does not, however, properly handle eSATA hot-swapping. Consequently, in order to notice new drives as they come on, you have to unload and reload the sata_sil24 module after each drive activation/deactivation. The command sequence is (performed with rootly privileges; su, sudo -s, or logging in as 'root' will all work, depending on how your system is configured):
rmmod sata_sil24
modprobe sata_sil24
Subsequent exchange with Tom Hoops:
TH: What driver versionwas that David?
DC:(He refers here to the Driver for the PCI based Silicon Image SI3124 controller chip)That's the built-in open source one that comes with all 2.6.26+ kernels. From what I gathered, Silicon Image put a lot of effort and knowledge into the open sourced one.
TH:
Awesome news David - thanks. However, I'm afraid of one thing. If you have to pop the driver everytime you pull a drive, doesn't that take all the drives down?
DC:
Briefly, yes. That brings us to the next step:
hdparm -W0 /dev/sd*
That turns off the write cache on all of the drives. Of course, if you have SATA drives that aren't High-Rely drives, you'll need to do each one manually (e.g. hdparm -W0 /dev/sda, hdparm -W0 /dev/sdb, and so on; checking in /var/log/syslog where the system is putting the High-Rely drives will be necessary).
TH:
Well, I suppose that is acceptable if you're going to use the system like a Robotic Tape System for back up (Mon drive 1, Tues, drive 2, Wed Drive 3 ...). But won't it cause IO errors if drives are active and doing things (if you were say, using them for storage) when you boink the driver?
DC:
I would imagine so, yes. Then again, I'm just using it for nightly backups and only swapping one drive a week; consequently, a weekly cron job on, say, Monday afternoon should keep that to a minimum on my end. That doesn't mean I recommend this solution for everyone. It's still better than nothing, though.
From what I've read, it would appear that eSATA-connected hard drive enclosures are just generally problematic with Linux; heck, the only reason I tried dropping and reloading the driver in the first place was because I wanted to find a way to detect the drives that didn't involve rebooting the server. For all I know, later kernels might handle this better; then again, maybe not.
At this point, I'm just providing this info because I think it's fun. Plus, hey, why not?
It turns out that, in Linux, it is possible to accomplish a "HRDM"-style approach using volume IDs. However, the catch is that you need to reformat each High Rely drive in either ext2 or ext3 format; at the very least, it's rather helpful. There are plenty of walkthroughs that can take care of that; personally, I found this one to be fairly useful: http://www.ehow.com/how_1000631_hard-drive-linux.html
Once you have each High-Rely formatted, you then just need to set up mount points based on the disk labels. To do that, create some folders that you'll mount the drives in. Ubuntu-based systems will usually create a /media folder that it'll drop anything and everything into, so, following in that short-lived tradition, you can do something like...
/media/Mon
/media/Tue
/media/Wed
/media/Thu
/media/Fri
/media/Sat
/media/Sun
Or whatever. Then, once they're formatted, you just need to grab their IDs using tune2fs thusly:
root@petro1:/media/backup# tune2fs -l /dev/sda1
tune2fs 1.41.3 (12-Oct-2008)
Filesystem volume name:
Last mounted on:
Filesystem UUID: d7d97588-a8e8-459c-a23f-ec4141e20483
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 91578368
Block count: 366284000
Reserved block count: 18314200
Free blocks: 360485712
Free inodes: 91578357
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 936
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Filesystem created: Fri Apr 30 14:01:28 2010
Last mount time: n/a
Last write time: Fri Apr 30 14:08:28 2010
Mount count: 0
Maximum mount count: 22
Last checked: Fri Apr 30 14:08:28 2010
Check interval: 15552000 (6 months)
Next check after: Wed Oct 27 14:08:28 2010
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 3265b526-b439-425e-914a-5735de0b2c8d
Journal backup: inode blocks
What you'll care about is the UUID. For each drive, just create a corresponding entry in your /etc/fstab thusly:
UUID=d7d97588-a8e8-459c-a23f-ec4141e20483 /media/Mon ext3 user_xattr,acl,data=journal,sync 0 3
What this particular entry does is it maps the UUID of the my /dev/sda1 partition to /media/Mon, tells fstab that it's an ext3 file system (it is), turns on some flags so I can share it via Samba if I'm so inclined (user_xattr and acl provide NTFS-style ACLs), while data=journal and sync are there to help guarantee that the file system is writing to the drive as soon as possible. The 0 tells fstab to avoid backing it up, and the 3 tells it to check the volume for integrity from time to time and, just as importantly, in what order compared to the rest of the volumes on the system.
Then just rinse, lather, and repeat. Once you do that, it doesn't matter what order the drives load up (/dev/sdX), they'll automatically go to the correct mount points.
Enjoy!
Now that Ubuntu 10.04 LTS is out, I might give that a whirl and see if that works any better; I was trying the beta for a bit but one of the versions caused my server to fail to boot.
TH: Thanks David!
|
