Re: dumping large partition to USB drive fails
On Wed, 27.06.2007 at 08:12:06 +0200, Roland Smith wrote: Unfortunately I can't check the drives with smartctl; they produce an SCSI error. I'll try 'camcontrol defects', and see if that turns up anything. Please try with atausb. Remove umass/da/scsi from your kernel and add atausb. Might be worth a try. Other than that, I wish FreeBSD could somehow translate those SMART commands, so it would work with USB/Firewire enclosures of all sorts. Cheers, Ulrich Spoerlein -- The trouble with the dictionary is you have to know how the word is spelled before you can look it up to see how it is spelled. -- Will Cuppy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dumping large partition to USB drive fails
On Sun, Jul 01, 2007 at 10:19:03AM +0200, Ulrich Spoerlein wrote: On Wed, 27.06.2007 at 08:12:06 +0200, Roland Smith wrote: Unfortunately I can't check the drives with smartctl; they produce an SCSI error. I'll try 'camcontrol defects', and see if that turns up anything. Please try with atausb. Remove umass/da/scsi from your kernel and add atausb. Might be worth a try. I tested the disk by putting it in another computer and running the manufacturer's diagnostic from the ultimate boot CD (www.ultimatebootcd.com) and it was fine. Other than that, I wish FreeBSD could somehow translate those SMART commands, so it would work with USB/Firewire enclosures of all sorts. It turned out that my enclosure used a USB/firewire chip with known problems, the Prolific PL3507 which has a problem with large transfers. I've ditched it. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpKe4mhjlBgr.pgp Description: PGP signature
Re: dumping large partition to USB drive fails
On Thu, Jun 28, 2007 at 02:53:31AM +1000, Norberto Meijome wrote: On Wed, 27 Jun 2007 17:05:08 +0100 Alex Zbyslaw [EMAIL PROTECTED] wrote: Manufacturer's diagnostics. Usually: download from manufacturer site, burn onto CD, reboot from CD, voila. good point. these may already be part of the Ultimate boot CD http://www.ultimatebootcd.com/ - never leave home without it ! ;) An update on how it went; I tested the drive in an old PC with the Western Digital tool from the ultimate boot CD. The diagnostics produced no errors. A tip from Paul Mather pointed to problems with USB/firewire chipset, the PL-3507, which was what I found in my enclosure. Most likely this is the culprit. I'm going to buy a new enclosure. Thanks for the help, everybody. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpidkg92zH8m.pgp Description: PGP signature
Re: dumping large partition to USB drive fails
On Thu, Jun 28, 2007 at 08:55:46PM +0200, Roland Smith wrote: A tip from Paul Mather pointed to problems with USB/firewire chipset, the PL-3507, which was what I found in my enclosure. Most likely this is the culprit. I'm going to buy a new enclosure. Can you provide these details (forward what Paul sent you, etc.)? It would be nice to have this info somewhere in the archives in case someone mails about similar... Thanks! -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dumping large partition to USB drive fails
On Thu, Jun 28, 2007 at 12:24:15PM -0700, Jeremy Chadwick wrote: On Thu, Jun 28, 2007 at 08:55:46PM +0200, Roland Smith wrote: A tip from Paul Mather pointed to problems with USB/firewire chipset, the PL-3507, which was what I found in my enclosure. Most likely this is the culprit. I'm going to buy a new enclosure. Can you provide these details (forward what Paul sent you, etc.)? It would be nice to have this info somewhere in the archives in case someone mails about similar... Here it is; I don't have your original posting, so I don't know what model of chipset you have, though I do dimly recall it being a Prolific, which is why I thought I'd e-mail you. Given that the PL3507 had an early history of problems when writing to it using large transfers (and that GELI uses large transfers, IIRC), and you say that enclosure is old, you might want to see if chipset bugs are the source of your problem. Here is a link I had bookmarked when I was looking for firmware updates for the Prolific PL3507: http://missig.org/julian/blog/2004/06/10/prolific-pl3507-firewire-device/ Here is a link to the corruption issue that plagued various chipsets, including the Prolific PL3507: http://www.bustrace.com/delayedwrite/index.htm -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpiXrpteTMYh.pgp Description: PGP signature
Re: dumping large partition to USB drive fails
On 28 Jun 2007, at 9:06 PM, Roland Smith wrote: On Thu, Jun 28, 2007 at 12:24:15PM -0700, Jeremy Chadwick wrote: On Thu, Jun 28, 2007 at 08:55:46PM +0200, Roland Smith wrote: A tip from Paul Mather pointed to problems with USB/firewire chipset, the PL-3507, which was what I found in my enclosure. Most likely this is the culprit. I'm going to buy a new enclosure. Can you provide these details (forward what Paul sent you, etc.)? It would be nice to have this info somewhere in the archives in case someone mails about similar... Here it is; I don't have your original posting, so I don't know what model of chipset you have, though I do dimly recall it being a Prolific, which is why I thought I'd e-mail you. Given that the PL3507 had an early history of problems when writing to it using large transfers (and that GELI uses large transfers, IIRC), and you say that enclosure is old, you might want to see if chipset bugs are the source of your problem. Here is a link I had bookmarked when I was looking for firmware updates for the Prolific PL3507: http://missig.org/julian/blog/2004/06/10/prolific-pl3507-firewire- device/ Here is a link to the corruption issue that plagued various chipsets, including the Prolific PL3507: http://www.bustrace.com/delayedwrite/index.htm My apologies for not doing a reply all when responding to Roland initially. As a bit of extra context to the above, a while ago I bought a cheap external FireWire/USB DVD writer for my iBook G4. I was disappointed to discover upon using it that its read performance when using the FireWire interface was much poorer than when using its USB connector. (It annoyed me especially because I had bought something that supported FireWire because I wanted to daisy-chain it with my Western Digital MyBook external hard drive to avoid using up one of the two USB ports on my iBook.) Because the FireWire and USB performance of my MyBook external hard drive is good, I doubted the problem lay with the iBook, and suspected the enclosure chipset instead. When I began searching the Web for information about the Prolific PL3507 chipset, used in the enclosure, I quickly began discovering horror stories (see above links for a taste). I realised that, if I had my time over and had known this DVD writer's enclosure used that chipset, I would not have bought it and would have looked for something whose enclosure used a different one (e.g., Oxford). I also realised that not all enclosures are created equal, and it's definitely worthwhile to know what chipset it uses beforehand and make sure you avoid the bad ones (like the Prolific). :-) Somewhat fortunately, revisions B and C of the Prolific PL3507 can have their firmware upgraded via USB. (Unfortunately, Prolific only appear to make a Windows flash writer application available.) It seems that the latest firmware at least appears to correct the worst excesses of the chipset, though people do still seem to harbour mistrust over the hardware and complain of performance problems. Although I have no plans to buy another enclosure for this DVD writer (because it works well enough for the task in hand), I think I would were it housing a hard drive, if nothing else because of the poor performance relative to the WD MyBook. Cheers, Paul. e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dumping large partition to USB drive fails
On Wed, Jun 27, 2007 at 03:32:21PM +1000, Norberto Meijome wrote: On Tue, 26 Jun 2007 08:09:48 +0200 Roland Smith [EMAIL PROTECTED] wrote: On Mon, Jun 25, 2007 at 10:45:07PM -0400, Yoshihiro Ota wrote: It's probabry your disk is dying based on your output. I've being using GELI for while, i.e. like a year, with dump/resotre, too. I never had problems with dump/restore. My disk also failed recently with very similer messages. The weird thing is, when I use the USB disk without encryption, it works fine. what happens if you dump your GELI partition first, and then the others? I haven't tried that yet. But I did try dumping to another USB disk with identical harddisk but slightly different enclosure, which worked fine. So I guess that Yoshihiro is right, and the disk is crapping out. Or the enclosure is malfunctioning. Unfortunately I can't check the drives with smartctl; they produce an SCSI error. I'll try 'camcontrol defects', and see if that turns up anything. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpB3ZVLWFsZe.pgp Description: PGP signature
Re: dumping large partition to USB drive fails
On Wed, 27 Jun 2007 08:12:06 +0200
Roland Smith [EMAIL PROTECTED] wrote:
Unfortunately I can't check the drives with smartctl; they produce an SCSI
error. I'll try 'camcontrol defects', and see if that turns up anything.
possibly because of the USB enclosure.
I've had very mixed results with USB cases - some great, some dying for no
reason, some working on and off. I would test the drive itself outside the USB
enclosure (hopefully you have one that can be pulled apart) and see how that
goes.
_
{Beto|Norberto|Numard} Meijome
I abhor a system designed for the 'user', if that word is a coded pejorative
meaning 'stupid and unsophisticated'. Ken Thompson
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dumping large partition to USB drive fails
On Wed, Jun 27, 2007 at 08:19:05PM +1000, Norberto Meijome wrote: On Wed, 27 Jun 2007 08:12:06 +0200 Roland Smith [EMAIL PROTECTED] wrote: Unfortunately I can't check the drives with smartctl; they produce an SCSI error. I'll try 'camcontrol defects', and see if that turns up anything. Well, camcontrol didn't work either. :-( possibly because of the USB enclosure. I've had very mixed results with USB cases - some great, some dying for no reason, some working on and off. I would test the drive itself outside the USB enclosure (hopefully you have one that can be pulled apart) and see how that goes. These ones are relatively easy to disassemble, luckily. I have two enclosures of the same brand, but the older (malfunctioning) one has both USB 2 and firewire connections, while the newer one just has a USB 2 connection. See http://www.conceptronic.nl/site/desktopdefault.aspx?tabindex=0tabid=200Cat=60grp=6010ar=450Prod_ID=1393Prod=CHD3UL I'll disassemble the malfunctioning drive, put it in an old PC and run smartctl on it. Are there any other tests that might be worthwhile? Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpaMFNaBpTOp.pgp Description: PGP signature
Re: dumping large partition to USB drive fails
On Wed, Jun 27, 2007 at 05:11:23PM +0200, Roland Smith wrote: Well, camcontrol didn't work either. :-( This doesn't come as much of a surprise; camcontrol expects to talk to a native SCSI device (your drive is ATA). atacontrol expects to talk to a native ATA device, but via adXX, not via umass or any other USB interface. I don't know of any software even on Windows (for comparison) that lets you get SMART stats off of an ATA drive in a USB enclosure via USB. These ones are relatively easy to disassemble, luckily. I have two enclosures of the same brand, but the older (malfunctioning) one has both USB 2 and firewire connections, while the newer one just has a USB 2 connection. See http://www.conceptronic.nl/site/desktopdefault.aspx?tabindex=0tabid=200Cat=60grp=6010ar=450Prod_ID=1393Prod=CHD3UL I'll disassemble the malfunctioning drive, put it in an old PC and run smartctl on it. Are there any other tests that might be worthwhile? Try a different manufacturer's product and see if it has the same problem? Many of these external enclosure products are badly (read: cheaply) engineered. Here's a story: A co-worker of mine owned one which kept dropping off the bus randomly, and when it was on the bus, it would occasionally error out during a transfer. Upon opening the enclosure (and violating the warranty), I found that the 2 long ATA33 cable (which was amusing in itself since the device claimed to support ATA100/ATA133 speeds) connecting the drive to the ATA-USB backplane had a couple copper wires exposed, and two of the wire crimping pins were actually sticking outside of the 40-pin connector. I replaced the 2 ATA33 cable with the shortest ATA66 cable I could find (about 6), which took some work folding it inside such a small space (and probably not good for the copper!) -- and it worked. All the problems were fixed, and the drive throughput nearly doubled. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dumping large partition to USB drive fails
Roland Smith wrote: I'll disassemble the malfunctioning drive, put it in an old PC and run smartctl on it. Are there any other tests that might be worthwhile? Manufacturer's diagnostics. Usually: download from manufacturer site, burn onto CD, reboot from CD, voila. If you are seriously dubious about the disk then run SMART long test. The smartctl man page has the details. But no manufacturer ever wants to accept a return unless their own diagnostics fail :-( --Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dumping large partition to USB drive fails
On Wed, 27 Jun 2007 09:03:21 -0700
Jeremy Chadwick [EMAIL PROTECTED] wrote:
Upon opening the enclosure (and violating the warranty), I found that
the 2 long ATA33 cable (which was amusing in itself since the device
claimed to support ATA100/ATA133 speeds) connecting the drive to the
ATA-USB backplane had a couple copper wires exposed, and two of the
wire crimping pins were actually sticking outside of the 40-pin
connector.
yeah...not surprised at all that's why I try to get the ones you can see
all the bits , no closed hardware :) BlueEyes seem to be quite reliable...
/me looks around for some wood...
_
{Beto|Norberto|Numard} Meijome
If you find God, do you get to keep him/her?
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dumping large partition to USB drive fails
On Wed, 27 Jun 2007 17:05:08 +0100
Alex Zbyslaw [EMAIL PROTECTED] wrote:
Manufacturer's diagnostics. Usually: download from manufacturer site,
burn onto CD, reboot from CD, voila.
good point. these may already be part of the Ultimate boot CD
http://www.ultimatebootcd.com/ - never leave home without it ! ;)
_
{Beto|Norberto|Numard} Meijome
Software is like sex, its better when its free
Linus Torvalds
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dumping large partition to USB drive fails
On Wed, Jun 27, 2007 at 09:03:21AM -0700, Jeremy Chadwick wrote: On Wed, Jun 27, 2007 at 05:11:23PM +0200, Roland Smith wrote: Well, camcontrol didn't work either. :-( This doesn't come as much of a surprise; camcontrol expects to talk to a native SCSI device (your drive is ATA). atacontrol expects to talk to a native ATA device, but via adXX, not via umass or any other USB interface. I don't know of any software even on Windows (for comparison) that lets you get SMART stats off of an ATA drive in a USB enclosure via USB. Bummer. Upon opening the enclosure (and violating the warranty), I found that the 2 long ATA33 cable (which was amusing in itself since the device claimed to support ATA100/ATA133 speeds) connecting the drive to the ATA-USB backplane had a couple copper wires exposed, and two of the wire crimping pins were actually sticking outside of the 40-pin connector. I took the unit apart because I had to check the HD's serial number anyway. The connectors looked ok. No visible flaws. The drive was correctly set up as master. It's interesting that the old enclosure feels hotter then the new one, even though they contain the same type HD. Unfortunately the HD itself just passed the warranty date. :( Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgphmX0lr43Fk.pgp Description: PGP signature
Re: dumping large partition to USB drive fails
On Thursday 28 June 2007 01:33, Jeremy Chadwick wrote: On Wed, Jun 27, 2007 at 05:11:23PM +0200, Roland Smith wrote: Well, camcontrol didn't work either. :-( This doesn't come as much of a surprise; camcontrol expects to talk to a native SCSI device (your drive is ATA). atacontrol expects to talk to a native ATA device, but via adXX, not via umass or any other USB interface. I don't know of any software even on Windows (for comparison) that lets you get SMART stats off of an ATA drive in a USB enclosure via USB. Speedfan (http://www.almico.com/speedfan.php) lets you read SMART off HDs. Also I don't think smartctl or FreeBSD are to blame for the inability to send SMART commands to the HD - it is the enclosures fault for not remapping the commands. (Which should be trivial, the commands are identical just the transport is different) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpg6oLzHzibJ.pgp Description: PGP signature
Re: dumping large partition to USB drive fails
On Mon, Jun 25, 2007 at 10:45:07PM -0400, Yoshihiro Ota wrote: It's probabry your disk is dying based on your output. I've being using GELI for while, i.e. like a year, with dump/resotre, too. I never had problems with dump/restore. My disk also failed recently with very similer messages. The weird thing is, when I use the USB disk without encryption, it works fine. So, dumping a non-encrypted partition to an encrypted disk works. As does dumping from an encrypted partition to a non-encrypted disk. Only in the case of where both are encrypted it fails. I tried testing the USB disk with smartctl, but it failed with a SCSI command error. :-( Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgphn7Qog39vQ.pgp Description: PGP signature
Re: dumping large partition to USB drive fails
On Tue, 26 Jun 2007 08:09:48 +0200
Roland Smith [EMAIL PROTECTED] wrote:
On Mon, Jun 25, 2007 at 10:45:07PM -0400, Yoshihiro Ota wrote:
It's probabry your disk is dying based on your output.
I've being using GELI for while, i.e. like a year, with dump/resotre,
too. I never had problems with dump/restore.
My disk also failed recently with very similer messages.
The weird thing is, when I use the USB disk without encryption, it works
fine.
what happens if you dump your GELI partition first, and then the others?
_
{Beto|Norberto|Numard} Meijome
Software is like sex, its better when its free
Linus Torvalds
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
dumping large partition to USB drive fails
Some background; I'm using a 160GB USB harddisk to write dumps to. This disk is encrypted with GEOM_ELI; umass0: Prolific Technology Inc. Mass Storage Device, rev 2.00/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: WDC WD25 00JB-00REA0 20.0 Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) GEOM_ELI: Device da0.eli created. GEOM_ELI: Encryption: AES-CBC 256 GEOM_ELI: Crypto: software Since I've converted my largest partition (/home) to GEOM_ELI as well, I'm having trouble making backups. slackbox:~$ df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/ar0s1a496M 88M368M19%/ devfs 1.0K1.0K 0B 100%/dev /dev/ar0s1g.eli120G 65G 46G59%/home /dev/ar0s1e496M 24K456M 0%/tmp /dev/ar0s1f 19G4.5G 13G25%/usr /dev/ar0s1d1.9G147M1.6G 8%/var /dev/da0.eli 226G100G107G48%/mnt/root Backing up non-encrypted partitions like /, /usr and /var works fine. But when I get to /home, the following happens; (da0:umass-sim0:0:0:0): AutoSense Failed GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165967687 68, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165968998 40, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165970309 12, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165971619 84, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165972930 56, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165974241 28, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165975552 00, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165976862 72, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165966376 96, length=131072)] g_vfs_done():da0.eli[WRITE(offset=116596768768, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116596899840, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116597030912, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116597161984, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116597293056, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116597424128, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116597555200, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116597686272, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116596637696, length=131072)]error = 5 GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=65536, len gth=2048)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=6144000, l ength=16384)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=6160384, l ength=6144)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1161638707 20, length=16384)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1163565137 92, length=16384)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165491568 64, length=16384)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165979484 16, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165980794 88, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165982105 60, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165983416 32, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165984727 04, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165984727 04, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165986037 76, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165987348 48, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165988659 20, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165978173 44, length=131072)] g_vfs_done():da0.eli[WRITE(offset=65536, length=2048)]error = 5 g_vfs_done():da0.eli[WRITE(offset=6144000, length=16384)]error = 5 g_vfs_done():da0.eli[WRITE(offset=6160384, length=6144)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116163870720, length=16384)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116356513792, length=16384)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116549156864, length=16384)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116597948416, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116598079488, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116598210560, length=131072)]error
Re: dumping large partition to USB drive fails
It's probabry your disk is dying based on your output. I've being using GELI for while, i.e. like a year, with dump/resotre, too. I never had problems with dump/restore. My disk also failed recently with very similer messages. Hiro On Mon, 25 Jun 2007 19:40:45 +0200 Roland Smith [EMAIL PROTECTED] wrote: Some background; I'm using a 160GB USB harddisk to write dumps to. This disk is encrypted with GEOM_ELI; umass0: Prolific Technology Inc. Mass Storage Device, rev 2.00/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: WDC WD25 00JB-00REA0 20.0 Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) GEOM_ELI: Device da0.eli created. GEOM_ELI: Encryption: AES-CBC 256 GEOM_ELI: Crypto: software Since I've converted my largest partition (/home) to GEOM_ELI as well, I'm having trouble making backups. slackbox:~$ df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/ar0s1a496M 88M368M19%/ devfs 1.0K1.0K 0B 100%/dev /dev/ar0s1g.eli120G 65G 46G59%/home /dev/ar0s1e496M 24K456M 0%/tmp /dev/ar0s1f 19G4.5G 13G25%/usr /dev/ar0s1d1.9G147M1.6G 8%/var /dev/da0.eli 226G100G107G48%/mnt/root Backing up non-encrypted partitions like /, /usr and /var works fine. But when I get to /home, the following happens; (da0:umass-sim0:0:0:0): AutoSense Failed GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165967687 68, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165968998 40, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165970309 12, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165971619 84, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165972930 56, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165974241 28, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165975552 00, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165976862 72, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165966376 96, length=131072)] g_vfs_done():da0.eli[WRITE(offset=116596768768, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116596899840, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116597030912, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116597161984, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116597293056, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116597424128, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116597555200, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116597686272, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116596637696, length=131072)]error = 5 GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=65536, len gth=2048)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=6144000, l ength=16384)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=6160384, l ength=6144)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1161638707 20, length=16384)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1163565137 92, length=16384)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165491568 64, length=16384)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165979484 16, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165980794 88, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165982105 60, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165983416 32, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165984727 04, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165984727 04, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165986037 76, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165987348 48, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165988659 20, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165978173 44, length=131072)] g_vfs_done():da0.eli[WRITE(offset=65536, length=2048)]error = 5 g_vfs_done():da0.eli[WRITE(offset=6144000, length=16384)]error = 5
