IEEE1394 FireWire Disks: Admin Guide
Linux kernels 2.4.12 and above contain support for ieee1394 devices,
including disk drivers. (Support can be added to some earlier kernels).
The RedHat 7.3 release we use (19 September,
2002) uses kernel 2.4.18-3, and by default is built with package
hotplug-2002_04_01-3.
There is sketchy documentation for hotplug available at
linux-hotplug.sourceforge.net. Info on ieee1394 for linux
can be found at
www.linux1394.org.
From man 8 hotplug:
/proc/sys/kernel/hotplug -- specifies hotplug program path
/sbin/hotplug -- hotplug program (default path name)
/etc/hotplug/* -- hotplug files for USB, PCI, ieee1394, etc.
/etc/hotplug/NAME.agent -- hotplug system-specific agents
X /etc/hotplug/NAME* -- subsystem-specific files, for agents
X /etc/hotplug/NAME/* -- driver setup scripts, invoked by agents
X /etc/init.d/hotplug -- hotplug system service script
The above files marked X do not exist in the RH7.3 distribution,
or do not exist for ieee1394.
/proc/sys/kernel/hotplug contains the name of the program to invoke
when something is hotplugged. This contains /sbin/hotplug.
/sbin/hotplug is a BASH script. When an IEEE1394 device is plugged/
unplugged, this script invokes /etc/hotplug/ieee1394.agent.
/etc/hotplug/ieee1394.agent is a BASH script. It is invoked with
parameters describing the action to take, and vendor ID and other
particulars of the device involved. When a disk is connected, it
is invoked with action "add". When the disk is disconnected, it is
invoked with action "remove". (for testing purposes, I added a line
to ieee1394.agent on puffin so that it logs the action each time it is called).
The linux hotplug
docs indicate that you can supply your own /sbin/hotplug
or /etc/hotplug/ieee1394.agent scripts. So far, we have simply
used the scripts supplied with RH7.3.
NOTE: This is all that is necessary on puffin and pelican, which are
SCSI-based machines. However, emperor is apparently a source of difficulty
since it is IDE-based. Or perhaps there is some other, more sinister
reason. Regardless, the relevant ieee1394 and ohci1394 modules do not
get automatically loaded on boot, NOR does adding the command
"/sbin/modprobe ohci1394" to /etc/rc.local work. To make sure that the
modules are available, it was necessary to use the pure System V approach:
- Upgraded to the latest hotplug package from RedHat "rawhide" experimental
release (there have been recent changes to hotplug scripts).
- Created a firewire script in /etc/rc.d/init.d
- Made the relevant runlevel links in /etc/rc.d/rc0.d-rc6.d: S99firewire
for runlevels 2-5 (startup last), and K96firewire for runlevels 0,1,6.
This approach actually loads the ieee1394 and ohci1394 modules at boot time.
sbp2 is then loaded automatically when the disk is plugged in.
WARNING: This does the job on emperor if it is running the original
RedHat 7.3 kernel, 2.4.18-3smp or 2.4.18-3. Upgrading to the so-called
strongly recommended bugfixed and security-patched kernel for 7.3,
2.4.18-27.7.xsmp, breaks the default FireWire procedure. Using the custom
scripts provided by linux1394.org, it is possible to get FireWire working,
but only for a single hotplug. Any attempts to plug a disk in a second time
cause emperor to hang. So, no matter how much RedHat begs, don't upgrade
the kernel just yet.
The following modules are used to access the disk, noted in the
order they are loaded.
Return to top of page.
Connecting and recognizing a disk
After a fresh system reboot, the kernel doesn't know anything about any
ieee1394 disks, even if they are connected at the time. It will not know
anything about it if you connect a disk drive after the system is
booted. In order to recognize the disks, the ieee1394 and ohci1394
modules must be loaded:
#modprobe -v ohci1394
This loads both ieee1394 and ohci1394. /var/log/messages shows:
kernel: ohci1394: $Revision: 1.80 $ Ben Collins
kernel: ohci1394_0: OHCI-1394 1.0 (PCI): IRQ=[9] MMIO=[fafff000-fb000000] Max Packet=[2048]
If the disk is connected when ohci1394 is loaded, or if it was already
connected, the hotplug modules get called. The following messages now
appear in /var/log/messages. (The 1st line is from my
modification to /etc/hotplug/ieee1394.agent on puffin.)
logger: ieee1394.agent: action is add
/etc/hotplug/ieee1394.agent: Setup sbp2 for IEEE1394 product 0x0010b9/0x00609e/0x010483
kernel: ieee1394: sbp2: Driver forced to serialize I/O (serialize_io = 1)
kernel: ieee1394: sbp2: Node 0:1023: Max speed [S400] - Max payload [2048]
kernel: scsi2 : IEEE-1394 SBP-2 protocol driver
kernel: Vendor: Maxtor Model: 1394 storage Rev: v1.0
kernel: Type: Direct-Access ANSI SCSI revision: 06
kernel: Attached scsi disk sdb at scsi2, channel 0, id 0, lun 0
kernel: SCSI device sdb: 120103200 512-byte hdwr sectors (61493 MB)
kernel: sdb: sdb1
In this case, it shows that the disk was recognized, and assigned to
scsi device sdb (2nd scsi disk). (On a different computer, it might be
assigned to a different scsi device. Puffin uses sdb; emperor and pelican
use sda.).
For verification, we can #cat /proc/scsi/scsi. This
shows all scsi devices on the system, and should show our
newly-connected disk.
The disk can now be accessed, formatted with fdisk, mounted,
exercised, etc. Do not use parted to format
or partition the disk -- it causes the system to hang/crash.
Disconnecting the disk
Before disconnecting the disk, it must be umounted to avoid
corruption.
After disconnecting the data cable, /var/log/messages
shows that ieee1396.agent was called with the "remove" argument.
(The log entry is generated by my addition to ieee1396.agent on
puffin.)
At this point, #cat /proc/scsi/scsi still shows that the
disk is present. However, attempting to access it
(e.g., mount /dev/sdb1) results in an error message,
but no other ill effects.
#modprobe -r -v ohci1394 unloads ohci1394. Then
#cat /proc/scsi/scsi shows that the disk is gone.
Attempting to unload ieee1394 with #modprobe -r -v ieee1394
gives an error: device or resource busy.
At this point, we can reload ohci1394, and reconnect the disk's data
cable. The log file shows that the disk was seen and recognized. But
#cat /proc/scsi/scsi fails to see the disk, and it
cannot be accessed until the system is rebooted.
Return to top of page.
What we did
- Load ohci1394 in /etc/rc.local. This is the last script
that gets executed during system startup. Now, any time after
startup, an ieee1394 disk connection will cause the disk to be
recognized. The entry in /etc/rc.local is:
/sbin/modprobe ohci1394
-
Add the following line to /etc/fstab and create the
corresponding directories:
/dev/sdb1 /local/fire vfat,ext3,ext2 noauto,users 0 0
(Note that on emperor and pelican, we use
sda1
instead of sdb1.)
During startup, the system attempts to mount the local filesystems
in /etc/fstab. The /dev/sdb1 entry
will fail, because ohci1394 is not loaded until later. Aside from
an error notice on the startup screen, this causes no ill effects.
-
Users issue the appropriate command to gain access
to their disks after connecting them:
mount -v /local/fire
and, when done,
umount /local/fire
Why we did it
-
By placing the entry in /etc/fstab, we can include the
user option. This allows each user to mount and
umount their own disk.
An alternative would be some kind of system automounting,
triggered by one of the hotplug scripts. This
would be far more work, especially since provision would have to
be made for umounting the filesystems.
-
After /etc/rc.local loads ohci1394, it is both unnecessary
and undesireable to unload it, even after a user disconnects a
disk drive. Therefore, no provision is made for
unloading/reloading this module.
Return to top of page.
Maxtor HDs come formatted with a single Windows VFAT32 partition. This
can be read and written from linux, but file ownership/protection doesn't
really exist in the unix sense.
Still, I would stay with vfat for maximum flexibility for
synchrotron trips. In this case, no reformatting or repartitioning is
necessary.
If you do want to reformat the disk for linux:
- As root, fdisk /dev/sdb to invoke the disk
formatting utility. (Use sda
on emperor).
-
Use "p" to print current partition list
-
Use "t" to change a partition.
- "1" to change partition 1
- "83" which is the hex ID for linux partition
- Use "w" to write partition table and exit
- Use mkfs -t ext3 /dev/sdb1 to create an ext3 filesystem
Once you reformat the disk for linux, it will not be recognized on a
windows system. You can't even reformat the disk on windows, because it will
refuse to acknowledge that the disk exists. So, on a linux computer, you
will have to reformat it back to vfat
Use the same procedure as formatting for linux, but enter "b" instead of
"83" for the partition code. Now, give the command:
mkfs.vfat -F 32 -v /dev/sdb1
You can now move the disk to a windows computer, which will recognize
it. (I then tried to reformat the disk on a windows system. After
40 minutes, it died, apparently failing to write the final partition
table. However, the disk was still usable both on windows and linux
systems.)
Return to top of page.
Last Modified: Wednesday, 04-Jun-2003 11:08:38 EDT by Art Perlo.