Printable View
Hi *,
I have recently spent time trying to make my USB external drive work
http://www.knoppix.net/forum/viewtopic.php?t=21063
It was suggested to me using the firewire port instead of the USB one
Any good firewire cards for Linux/Debian/knoppix?
Thanks
The good part I'm not too sure about, but there are three inexpensive cards that I have used or installed before that support Linux to some extent. http://www.newegg.com/Product/Produc...chInDesc=linuxQuote:
Any good firewire cards for Linux/Debian/knoppix?
These are based on the VIA or NEC chipsets. I have had some mixed results under windows with these, but if my memory serves me correctly, they all worked with Linux of one sort or another. This is another one I have used and worked OK without a song and dance. : http://www.newegg.com/Product/Produc...82E16815104218
I gave the links to NewEgg since that is where I purchased these particular units. I got most of the others along the long path of upgrades, Computer Shows, and Miscellaneous trades/swaps. I have several boxes full of 1394 and USB cards, so if one does not work, it's not a far trip to swap it out for another. USB cards are another story entirely and found many cards to be flaky with various versions of Linux over a period of time. I think the latest ones to "Have a Pox Upon Them" are the VIA chipset based USB cards. I think they are OK with Knoppix 4.0.2, but have not really verified that yet. All I can say is that one machine that has one installed, works OK with 4.0.2 and I'm almost certain it is a VIA chipset based USB card.
These cards are reasonable and appear to work well with many versions of Linux. I have a good supply of miscellaneous 1394 cards and have found few failures with them. I have a few older Adaptec, IOGear, IBM OEM, Koutech, and some other generic OEM Ti chipset units and they all seem to work. I have not had many issues with 1394 under Linux, but I'm probably just lucky and have not yet tried to check transfer rates, etc. Be careful about the 64 bit requirements if you select a 1394b card. Many motherboards are not able to support them. Out of them all, I have used the Adaptec the most and a few older discontinued Orange Micro cards without much trouble, mostly since I have a good supply of them. I have found almost any card that supports the later versions of the MAC OS to be just fine.
Basically, look around for a good deal, check the specs, and if it mentions Linux, you probably have a good chance of success. Even if it does not mention Linux, you have a good shot at it, especially if it mentions the MAC OS as compatible. If you have a particular brand that has worked well for you before, or is more available where you are located, it's worth a try and odds are it will work. I'm cheap, so when I can get a stack of used or pulled units for a song, I buy them. I'll find someplace for them to go. I use Firewire, have used it for years, like it much better than USB anything, and will prefer it to USB if I have the choice. Most of my externals are either 1394 only or dual USB/1394 units. I even use 1394 for a quick network between two systems on occasion. The only caveat might be using a 1394 external drive to write from, to a 1394 DVD writer on the same controller. The transfers are sometimes slow, so you might need to keep the burn speeds low (Under 2X). If you have two controllers in the PC, you are golden.
I found some more praises for the card you propose and some more info at
http://weblog.bbzzdd.com/archives/technology/linux/
// __ just a extract from there
July 25, 2005
Impossible
I know I didn't just pop in a 1394 (Firewire) card into my Linux box, turn it on, and it worked.
The goal is network storage on a removable disk. For all those Googling for "firewire linux" the steps are:
1. I am using kernel 2.6.12. Compile 1394 support along with OHCI-1394, SBP-2 , Raw IEEE1394 support all as modules. I don't know if you need the last one but it sounds good.
2. Compile SCSI device and disk support.
3. You may need to do some insmod magic, I didn't.
4. Shutdown, add card, whatever else.
5. tail -f /var/log/syslog and plug the drive in. You should see a bunch of messages from ieee1394 and sda. The drive should be /dev/sda1 or something around that depending on the other devices on your system.
6. Mount. mount -t vfat /dev/sda1 /mnt My drive is formatted as FAT32 for compatibility. What sucks is the maximum file size is 4GB. So much for archiving DVD images :(
If you're looking for a good Firewire card, Newegg has the Koutech PCI to 1394a Card Model IO-PFW310 for about $15 shipped ...
// __
July 27, 2005
External Disk for Windows, OS X, and Linux
I wanted to use my external Firewire drive on all my systems. I found that formatting the whole thing for FAT32 was not the answer. The best solution I came across was to make two partitions, one FAT32 and the other HFS+. Windows can read FAT32, OSX and Linux can read both. Super.
The best way to do it is under OS X (10.4.2 in my case) using diskutil. My drive is 160GB, so I did a 100GB FAT32 partition and a ~60GB HFS+ partition. It's as easy as:
diskutil partitionDisk disk2 2 MBRFormat MS-DOS FAT_VOL 100G HFS+ MAC_VOL 60G
Diskutil will figure out the change on the 60GB partition if you go over the free amount (it came to something like 55G).
You need the MBRFormat parameter if you want Windows to be able to read the FAT32 partition. If in doubt check the man page.
Using either disk under Linux 2.6.x is as easy as:
mount -t vfat /dev/sda1 /mnt/exthd1/
mount -t hfsplus /dev/sda2 /mnt/exthd2/
// __
Thanks
Albretch
You are quite welcome!
Good info. It appears correct. The Koutech card is pretty good, although the manufacturer web site does not list Linux as compatible. It does appear to work wherever I have placed one. The only issue I ever had with one was that I had to move it to a different slot in one PC. It was just a resource issue on that one system and worked flawlessly once it was relocated. There is little magic to Firewire and it appears to work well in most operating systems. It is my preference for external devices, especially when large file transfers are planned. Unfortunately, it is just not that popular anymore. I feel like the "BetaMax" user of a time gone by long ago. Apple had it right in the beginning. Small stuff moved by USB. Larger stuff needed a freight train, so it went by 1394. I used to think that my pair of LaCie DVD-RAM drives on a G3 was the ultimate. The drives now reside in a closet and the G3 is long gone. BUT my use of 1394 remains and it has rarely given me any issues in whatever platform I use it in. The only issue is with needing to use multiple controllers to transfer from one device to another at higher data rates if required. This was most apparent for me with Windows, but appears to apply to all platforms.
One word of caution regarding FAT32 partitions and Windows 200 and XP. The maximum supported size for a FAT32 partition is 32Gig. It can become corrupted if it is larger, or may not read/write properly. I have had systems lock up while trying to access larger FAT32 partitions. I'm not sure that the solution offered in your link will cure that issue. Windows 98 or ME may be OK with it. If you are looking to have full access from all OS versions, you might consider several 32G partitions in FAT32 and then whatever else you planned on.
> The maximum supported size for a FAT32 partition is 32Gig
Even from a firewire drive?
Albretch
Where are you getting this information? Everything I know says that XP supports FAT partoitions larger than 32 gig just fine. There is an issue that the tools that come with XP will not let you create a FAT partition larger than that, but that is because MS wants to push NTFS, not because of any size issue with FAT partitions. My XP clearly documents that it will read and write to larger FAT partitions created by older MS Operating Systems.Quote:
Originally Posted by ckamin
Sorry about the confusion and thanks, Harry, for the wakeup call. :oops: I wrote that reply after 30+ hours without sleep running on stale sandwiches and day-old coffee. I looked it over again after a three hour nap and came up with the same question: What were you thinking? It looked OK through the two ton eyelids I had before, but I see your point after reading it over. The recommendations are valid but the reasoning and other data is incomplete and skewed. Please allow me to clarify and complete the information to end the confusion.Quote:
Where are you getting this information?
This refers ONLY to an externally attached drive using USB or Firewire and in no way refers to an internally attached drive or other type of device. The discussion is intended to refer to an external drive so attached, so I need to make that point clear that it also applies for the rest of the information in THIS discussion as well, unless stated otherwise.
Windows XP and 2000 have a limitation that prevents them from formatting a partition, larger than 32 Gig, as the FAT32 file system. That applies to BOTH internal and external drives.
FAT32 is problematic for large files, since it is limited to 4Gig file sizes. That is OK for ten years ago, but I have loads of stuff that exceeds that capacity limitation. Why play with file splitting if all I need to do is use a different file system.
The recommendation to setup 32 Gig partitions instead of a larger one comes from the efficiency of the drive. It is better to limit the cluster size to 4k just as the default size in the NTFS file system, primarily to better utilize the space. It also helps the data transfer rate a little. The primary reason to use FAT32 here is cross-platform write compatibility. Remember you can still READ NTFS with Linux, just fine!
Now for the corruption issue. I have personally experienced several dozen instances where an EXTERNAL drive that has been formated as FAT32 in one large partition had become unreadable in windows. They were attached to Win XP or 2000 systems through USB or Firewire. They were reported after the failure to be of RAW format after failure in most of the instances, if not all. I have been made aware of even more of these ocurrences through reliable associates. No claim is made here that they were failures of internal drives attached to these PCs. I was only able to recover the information on a few of these affected drives. A data recovery service probably could have done it, but there was nothing on the drives that couldn't be replaced, that was worth that kind of money.
Since I did not yet experience an Internal drive failure such as these, does not mean it can't, or does not happen. It just means it has not yet happened to me. I have not been able to verify any "Reports" where this was alleged to have occurred either, so we will assume for now, that it applies to the External devices/drives described here.
In contact with various drive manufacturers and checking through the knowledgebase on a few drive manufacturer's support sites, verifies that there are occurences such as these. I offer the following links for further information:
http://wdc.custhelp.com/cgi-bin/wdc....i=&p_topview=1
http://maxtor.custhelp.com/cgi-bin/m...i=&p_topview=1
The second one from Maxtor IS relevent to this discussion and basically reads as follows:
Question
Cannot access the information on External drive.
Answer
Problem:
Cannot access information on External drive and may receive the following errors:
Drive is recognized as an unformatted or "RAW" drive.
The operation could not be Performed Because of an I/O Device Error
Parameter is incorrect
Cause:
The file system on the drive may be corrupted. This can be caused by a variety of reasons but the two most common reasons are improper disconnection of the external drive and using FAT32 as the file system in a Windows 2000 or XP system.
I am providing another link to a forum on the issue. The post there seems to discuss this issue. If it were that post alone, it would not convince me that anything would be amiss. My conversations with the drive manufacturers, my own experiences, experiences of my associates, what I have read previously about these failures, and common sense indicates that there is a valid concern with FAT32 and WIn XP/2000 in the circumstances described here. The link is as follows:
http://forums.livingwithstyle.com/ar...ntfs--p-1.html
I Have Win XP and 2000 systems running on larger than 32Gig FAT32 partitions and they are apparently working just fine, so far. I have used drives formatted as FAT32, and larger than 32Gig successfully in Win XP and 2000, and still do, on occasion. These remarks ONLY apply to INTERNALLY connected drives!
After encountering issues as I have described above, I simply do not use drives that are formatted fully in one large FAT32 partition. Multiple FAT32 partitions appeared to have worked, but I use FAT32 rarely with XP and 2000 anymore since experiencing these types of failures. Whatever drives are in place are there until I find the need to change them. Any new drives are NTFS for those reasons. I NOW do the same for Internal drives as well, since I do not want to take any chances. The exceptions to this are simply drives that need to read by multiple operating systems, such as the ones in this discussion. I have used the format as I discussed, with FAT32 Partitions 32Gig or smaller, and I have not experienced ANY failures since doing so.
Now for a few other pertinent tidbits.
Using an external USB or Firewire drive can circumvent most of the issues regarding drive size limitations in the Bios/Mainboard.
Some older Firewire DRIVE controllers/chipsets may/do have issues with drives over certain capacities. One example is the older Oxford chipset with drives much over about 120Gig, depending on how you count drive size. The drive size is not usually read properly by Windows or other OS. Formatting a drive elsewhere and then attaching it to the Oxford controller can cause data loss, incomplete file/data information, or data or a part of the drive being inaccessible. This issue should apply to ALL file systems. Be sure to check the specs for the enclosure you will be using. A firmware update for the affected controller might be available and could alleviate some of the issue.
It is wise to always "STOP" the external drive before unplugging it in Windows. Especially if data is being transferred at that exact moment. Murphy's law dictates that it will happen at the most inopportune time.
I apologize again for the confusion that my previous post caused. I hope this information has helped to clarify the information.
ckamin:
This is interesting information, I want to look into it more when I can find the time. I certainly had not heard of this issue with external drives before. Thanks.
It almost floored me when it became too big to ignore and realized what was probably happening. I do want to put this in perspective though. Most users will not ever experience one of these failures. It is a rare occurence, but it does happen, and happened to me more than it should have. I have not experienced ANY failures for the couple of years since I stopped using external FAT32 partitions over 32Gig, except for one, and that was due to a bad controller in a USB/Firewire controller. That failure was on an NTFS formated drive. A new external enclosure cured the problem for me and the issue has not recurred. I use quite a few external drives almost 24/7 and put them through the wringer. So if something will show up, it will probably show up here eventually. One note about the failure. If you are not planning on data recovery for the drive, a Zero-Write or Low-level format and re-format usually makes the drive serviceable again. Sometimes just a format does the trick, but I like to wipe the drive before the format, since you never know.Quote:
This is interesting information
I have had phone conversations with a few techies at more than one drive manufacturer that seem to support what the document from Maxtor said. One actually did expand that to include drives that are NOT externally connected. I just don't think I have experienced one of those failures on an internal drive yet, so I just apply that to externals and keep my fingers crossed. There is very little written out there to confirm all of this, but there is enough for concern.
It seems to have something to do with the MBR, Partition tables, etc., that appear to get corrupted for some reason. I am not qualified to really do the forensics on this, but I did recover a few drives by re-writing the boot record from an older version(fdisk /mbr). I then copied the data, if needed, and zeroed the drives then reformatted. They appeared to work OK after that, so I doubt any lasting damage was done to the hardware itself.
So whenever someone mentions using FAT32 as their file system on an external drive, I tell them to err on the side of caution and use multiple partitions of 32Gig or smaller. It actually can improve performance as a side benefit.
One other reason for the recommendation towards using 32Gig partitions is simply that they can be maintained by Windows XP/2000 (Formated, re-formated, etc.) and is a matter of convenience. I failed to mention that before.
I just thought it was Micro$oft being Micro$oft again. It's what they do best! I have stopped looking for a answer to this some time ago. Please let me know if you do find out anything useful while researching this. It would be interesting to know if it is just me getting "Chicken Little" syndrome. :)
At least this firewire interface has worked OK for me (so far so good ;-)).
I bought a:
SYBA PCI to Firewire 1394a 3+1 ports controller card Model SD-NEC-4F
http://www.syba.com/us/en/product/43/01/11/3/
from newegg for $14.29 (including s&h)
// __
knoppix@0[knoppix]$ su
root@0[knoppix]# modprobe ohci1394
root@0[knoppix]# modprobe raw1394
root@0[knoppix]# gscanbus
* X window opened and when I clicked on S400 Linux - ohci1394 I got some prop info
// __
root@0[knoppix]# ls -l /dev/sda*
brw-rw---- 1 root disk 8, 0 Apr 14 2001 /dev/sda
. . .
brw-rw---- 1 root disk 8, 15 Apr 14 2001 /dev/sda15
root@0[knoppix]# mkdir /mnt/sda
root@0[knoppix]# mount /dev/sda /mnt/sda
root@0[knoppix]# cd /mnt/sda
root@0[sda]# ls -l
total 28
drwxr-xr-x 30 root root 4096 Sep 26 06:22 __ext
drwxr-xr-x 2 root root 4096 Sep 26 06:22 findpart
drwxr-xr-x 39 root root 12288 Sep 6 10:31 gates
drwxr-xr-x 3 root root 4096 Oct 12 08:58 iso
drwxr-xr-x 2 root root 4096 Oct 12 00:10 knoppix
root@0[sda]#
// __ then for testing I went to the drive and created, edited and deleted files without any problems
// __
root@0[/]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 2.5M 15K 2.4M 1% /
/ramdisk 1.6G 11M 1.6G 1% /ramdisk
/UNIONFS 8.4G 6.9G 1.6G 82% /UNIONFS
/dev/hdc 3.2G 3.2G 0 100% /cdrom
/dev/cloop 5.1G 5.1G 0 100% /KNOPPIX
/dev/cloop2 1.8G 1.8G 0 100% /KNOPPIX2
/UNIONFS/dev/sda 75G 56G 20G 75% /mnt/sda
// __
root@0[/]# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/root 8192 53 8139 1% /
/ramdisk 223837 758 223079 1% /ramdisk
/UNIONFS 223837 758 223079 1% /UNIONFS
/dev/hdc 0 0 0 - /cdrom
/dev/cloop 0 0 0 - /KNOPPIX
/dev/cloop2 0 0 0 - /KNOPPIX2
/UNIONFS/dev/sda 0 0 0 - /mnt/sda
// __ what has been mounted (notice the FAT32 vfat external harddrive /mnt/sda type vfat (rw))
root@0[/]# mount
/dev/root on / type ext2 (rw)
/ramdisk on /ramdisk type tmpfs (rw,size=1645636k)
/UNIONFS on /UNIONFS type unionfs (rw,dirs=/ramdisk=rw:/KNOPPIX=ro:/KNOPPIX2=ro,delete=whiteout)
/dev/hdc on /cdrom type iso9660 (ro)
/dev/cloop on /KNOPPIX type iso9660 (ro)
/dev/cloop2 on /KNOPPIX2 type iso9660 (ro)
/UNIONFS/dev/pts on /UNIONFS/dev/pts type devpts (rw)
/proc/bus/usb on /proc/bus/usb type usbfs (rw,devmode=0666) automount(pid2031) on /mnt/auto type autofs (rw,fd=4,pgrp=2031,minproto=2,maxproto=4)
/UNIONFS/dev/sda on /mnt/sda type vfat (rw)
root@0[/]#
// __ unmounting the firewire device
root@0[sda]# cd ..
root@0[mnt]# cd ..
root@0[/]# umount /mnt/sda
root@0[/]# cd /mnt/sda
root@0[sda]# ls -l
total 0
// __
The NEC chipsets appear to have few issues in Linux, so you made a good selection. The best part was the low cost for the card AND shipping.Quote:
At least this firewire interface has worked OK for me (so far so good ).
I'm glad to see that it worked out for you!