Disk Behaviour with Linksys R63 Firmware

This article pertains to:

• Unslung 6.x only

Linksys version 2.3R63 has support for NTFS disks, and changes the handling of attached disks significantly from previous versions. This page documents our current knowledge about that new behaviour (which will be mainly preserved in Unslung 6.x).

Single FAT/NTFS device per port

FAT partitions are recognised on Disk1 (USB Port 1) and Disk2 (USB Port 2). NTFS partitions are only recognised on Disk1.

Multiple partitions per single device

Disk1 will mount multiple FAT and NTFS partitions. Disk2 will only mount FAT partitions.

Multiple FAT/NTFS devices per port (using a hub)

Multiple FAT/NTFS devices behind a hub are only recognised on USB Port 1.

On USB Port 2, only the first single device plugged in is mounted and any additional devices are ignored (even if the first device is subsequently disconnected).

Installation Recommendations

See WhichUSBPortforUnslung6.

If you want to use a hub with Unslung 6.x it has to be connected to USB Port 1. The firmware is able to recognize multiple disks behind the hub and mount them auto magically.

Unfortunately you can't put your root disk on the hub. The first found disk on the hub will be used as "/dev/sdb" and there is no reliable way to ensure that the root disk is always "/dev/sdb".

The best solution is to simply put the Unslung root disk on USB Port 2.

There is a discusion about this on the mailinglist.

Odd Behavior

rc.bootbin in 2.3R63 (and thus Unslung 6.x) behaves oddly when confronted with two native ext3 formatted drives. In short, it mounts the conf partition (number 2) of the device in slot 2 (/dev/sdb) in both /share/hdd/conf and /share/flash/conf! This is Very Bad since it effectively deletes your share configuration (and password file) every time it reboots, resulting in an odd appearance of tilde-1 versions of your shares.

For example, let's say you unslung to a flash drive in slot 2 and have a native-formatted hard disk in slot 1 (as suggested in numerous 6.x documents). Now you create a "music" share on the hard disk. This creates /share/flash/data/music and adds it to /share/flash/conf/share.info. Now you reboot. You will be surprised to find an unusable "music" share pointing to the nonexistant /share/hdd/data/music, and a usable but unmanageable "music~1" share pointing to /share/flash/data/music. Now reboot again. Your music share is gone (though the data remains).

The solution suggested as "exception to rule #1" in WhichUSBPortforUnslung6, putting the root (flash) device in port 1 and the usb disk in port 2, does not solve this problem. See NonNativeDiskMount for a workable solution.

Solution to Odd behaviour

Added 2009-12-29 by PaulBrandt?

Indeed the incorrect mounting of both drive's /conf onto /dev/sdb is the source of this issue. An apparent solution has been described in CorrectBadSharingWithTwoDrives . Thanks to Alain for pointing this out.

=====

I have ~never~ run into this problem in my 6.8 setup, and I consciously (but ineffectively, according to this article) elected to format BOTH 300Mb drives using Linksys's format util because I wanted to be able to "boot off the other one if the first one failed." (I had no idea that the second one's conf was being blown away each time.)

However, puzzling over why I never had a problem with my shares, I realized its because I never used the webpages to define them! Instead, I (apparently) edited smb.conf via ssh and used smbpasswd to create smbpasswd, only on the master disk. I accessed the second drive's "share" folders by putting links to them in the first drive's data/public folder, so it appeared that all my shares resided on disk 1. As a result, no share information lived on drive 2 so blowing it away never affected anything.

Sometimes it's better to be lucky than smart...

Of course, if disk 1 had exploded and I had tried to institute my mad plan of then booting off disk 2, THEN I would have been bit by disk 2 having disk 1's conf partition...

=====