off topic - disk crash
Today an important (no backup of course) 46 GB IBM Deskstar IDE disk crashed. It has a FreeBSD 4.8 on it with important data and programs. Yes, shame on me that I didn't care about doing backups on it but it has happened. I evend tend to expend the bucks to get it recovered but a little prediagnosis I would not to be left untried. The disk boots into FreeBSD but already at power on time the disk does seek retries or some recalibration noise. The question is what else can I do to recover the data. Put it in the icebox? Turn the computer upside down? Any ideas would be welcome. I thought of getting a second identical disk to exchange electronics only but since it partially functions it looks more like surface corruption, doesn't it? -- Chris Christoph P. U. Kukulies kukulies (at) rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: off topic - disk crash
Hi, C. Kukulies wrote on Wed, Mar 10, 2004 at 06:36:52PM +0100: [..] > The disk boots into FreeBSD but already at power on time the disk does > seek retries or some recalibration noise. > > The question is what else can I do to recover the data. > Put it in the icebox? Turn the computer upside down? [..] Put it into another box running a working FreeBSD and enough disk-space to contain all the contents of the damaged disk. Check if you can still read the disklabel (just do "disklabel ad1s1 (or whatever your device is)). If you can read the disklabel, grab the contents of each partition with dd, use the 'conv=noerror,sync' options to fill unreadable sectors with zeros. Turn the resulting partition-image files into devices using vnconfig. Now you can either: a) fsck the devices and then mount them to grab what is left of the data. This is the more reliable way, but fsck may render some data inaccessible. If the superblock is damaged, read fsck and newfs manpages, as well as the handbook, how to get a backup-copy of your superblock. b) mount the device read-only and grab what is left of the data. If the filesystem is badly damaged, this could panic your machine. So don't do it unless you really have to. You can make a copy of the partition image-files, and do the fsck on one copy. You still have the other one if you want to try without fsck. If you cannot read the disklabel, you can still use dd to make an image of the whole disk. But you will have to find the partition-boundaries for yourself. There is a tool in the ports to find filesystem boundaries, IIRC. I don't recall the name of this tool, though. HTH, Daniel -- IRCnet: Mr-Spock - Cool people don't move, they just hang around. - Daniel Lang * [EMAIL PROTECTED] * ++49 89 289 18532 * http://www.leo.org/~dl/ smime.p7s Description: S/MIME cryptographic signature
Re: off topic - disk crash
In the last episode (Mar 11), Daniel Lang said: > C. Kukulies wrote on Wed, Mar 10, 2004 at 06:36:52PM +0100: > [..] > > The disk boots into FreeBSD but already at power on time the disk > > does seek retries or some recalibration noise. > > > > The question is what else can I do to recover the data. Put it in > > the icebox? Turn the computer upside down? > > Put it into another box running a working FreeBSD and enough > disk-space to contain all the contents of the damaged disk. > > Check if you can still read the disklabel (just do "disklabel ad1s1 > (or whatever your device is)). > > If you can read the disklabel, grab the contents of each partition > with dd, use the 'conv=noerror,sync' options to fill unreadable > sectors with zeros. Also, if it looks like a single bad area of the disk, try a dd starting a couple megs past the bad spot (with iseek+oseek) if the drive stops responding after it hits the bad area. I recovered data from a failed disk this way. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: off topic - disk crash
You could also use dd with the bs/count operands to skip the bad blocks, but this will probably be much more frustrating that the conv operand. Another option (that is slower than dd but less stressful on the failing drive) I've used are the dump/restore utilities. I have the specific commands for Solaris, but the process should work for FreeBSD with some alterations (I can email it to you off list if you would like). This is the general procedure I use for the dump/restore utilities: 1. Attach second ide drive to cable/controller, same size or larger than the failing disk. This will be your recovery disk. 2. Boot from CD into single user mode (for freebsd check out www.freesbie.org site and/or use the port). 3. Format, partition, label (make sure it is bootable), and create the new file system on the recovery disk so it is identical to the old disk. 4. Fsck the new and failing disks. 5. Setup and verify your swap partition on the recovery disk. 6. Mount the recovery disk partition. 7. Dump/restore the old disk partition to the new disk partition. Repeat 6/7 for each partition. 8. Mount the failing disk partitions and compare to the recovery disk for consistency. 9. Unmount all disk partitions. 10. Shutdown the system, remove the failing drive/CD, power it back up, and test. -Marcus - Marcus Beaman Data Network Operations Analyst DAS/IRMD/ENS NOC 503-378-3627 - <---REPLY---> >Date: Thu, 11 Mar 2004 15:21:28 +0100 >From: Daniel Lang <[EMAIL PROTECTED]> >To: "C. Kukulies" <[EMAIL PROTECTED]> >Cc: [EMAIL PROTECTED] >Subject: Re: off topic - disk crash >> Hi, > > C. Kukulies wrote on Wed, Mar 10, 2004 at 06:36:52PM +0100: > [..] > > The disk boots into FreeBSD but already at power on time the disk > > does seek retries or some recalibration noise. > > > > The question is what else can I do to recover the data. > > Put it in the icebox? Turn the computer upside down? > [..] > > Put it into another box running a working FreeBSD > and enough disk-space to contain all the contents of > the damaged disk. > > Check if you can still read the disklabel > (just do "disklabel ad1s1 (or whatever your device is)). > > If you can read the disklabel, grab the contents of > each partition with dd, use the 'conv=noerror,sync' > options to fill unreadable sectors with zeros. > > Turn the resulting partition-image files into devices using > vnconfig. > > Now you can either: > > a) fsck the devices and then mount them to grab what is left > of the data. This is the more reliable way, but fsck may > render some data inaccessible. > If the superblock is damaged, read fsck and newfs manpages, > as well as the handbook, how to get a backup-copy > of your superblock. > > b) mount the device read-only and grab what is left of the data. > If the filesystem is badly damaged, this could panic your > machine. So don't do it unless you really have to. > > You can make a copy of the partition image-files, and do the > fsck on one copy. You still have the other one if you want > to try without fsck. > > If you cannot read the disklabel, you can still use dd to > make an image of the whole disk. But you will have to find > the partition-boundaries for yourself. There is a tool in the > ports to find filesystem boundaries, IIRC. I don't recall the > name of this tool, though. > > HTH, > Daniel <---END REPLY---> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: off topic - disk crash
C. Kukulies wrote: Today an important (no backup of course) 46 GB IBM Deskstar IDE disk crashed. It has a FreeBSD 4.8 on it with important data and programs. Yes, shame on me that I didn't care about doing backups on it but it has happened. I evend tend to expend the bucks to get it recovered but a little prediagnosis I would not to be left untried. The disk boots into FreeBSD but already at power on time the disk does seek retries or some recalibration noise. The question is what else can I do to recover the data. Put it in the icebox? Turn the computer upside down? Any ideas would be welcome. I thought of getting a second identical disk to exchange electronics only but since it partially functions it looks more like surface corruption, doesn't it? Its most likely the dreaded "deathstar syndrome" and yes that means the magnetic surface of the platters is worn thin or in some of the worse cases completely worn off.. To put it short, there isn't much hope for your data :( -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: off topic - disk crash
> Date: Wed, 10 Mar 2004 18:36:52 +0100 (CET) > From: "C. Kukulies" <[EMAIL PROTECTED]> > Subject: off topic - disk crash > To: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > > Today an important (no backup of course) 46 GB IBM Deskstar > IDE disk crashed. It has a FreeBSD 4.8 on it with important data and programs. > Yes, shame on me that I didn't care about doing backups on it but it > has happened. This specific line of drives is infamous for a failure rate that's at least a full order of magnitude above the industry average for ATA drives. Google a bit for it. I just spent a weekend replacing that exact model of drive and trying to recover data for our babysitter's (WinMe) computer, without success. > I evend tend to expend the bucks to get it recovered but a little > prediagnosis I would not to be left untried. > > The disk boots into FreeBSD but already at power on time the disk does > seek retries or some recalibration noise. > > The question is what else can I do to recover the data. > Put it in the icebox? Yes, this might actually help, provided the read head is not yet too badly damaged or stuck to the platter. One of the several problems with the drive seems to relate to overheating. > Turn the computer upside down? I'd remove the drive from its mounting and just hook it up loosely cabled into an open system while you try to recover. There's supposed to be some firmware update you can get from IBM to update the drive firmware, which can help reduce the chance of these errors and might help recover the data. If you can find the firmware update from IBM, boot a system in DOS with the drive hooked up, and run the flash utility, that might help with the following steps. > Any ideas would be welcome. > > I thought of getting a second identical disk to exchange electronics > only but since it partially functions it looks more like surface corruption, > doesn't it? From what I've read online part of the failure mode may have to do with stray particles of crud inside the platter area from a bad manufacturing process (or coming loose from the drive surface over time) attaching to the read head and resulting in a head crash. The other problem was that the drive sometimes didn't park the head safely on powerdown. It's very unlikely to be an electronics problem. It all depends how bad the crash is and what the current condition of the head and surface is whether you will get anything back off again. In my case I couldn't get past 5% into the drive using the disk utilities I had, but working in FreeBSD with its known data structures you might be able to do better. You've been given good-sounding advice about what to try on the software side by a previous poster. I recommend following the suggestion given by that poster. On the hardware side, before you start trying to copy the data off, first try this firmware update if you can find it (Google for it) and then make sure the drive is extremely well cooled while you're trying to copy the data off. Either prechill it or have it in open air with a fan blowing on it, or both. If you can't get it to start reading at all and can't get anything off, the head may be stuck to the disk. ONLY if you can't seem to get anywhere at all with it, in that case (sensitive types may want to shield their eyes at this point) you could try picking up the drive and banging it on the table once or twice only. Sometimes this will free the head on a crashed hard drive and let you read it long enough to recover the contents, though it tends to rapidly destroy working drives. I have done this very very rarely in my career, but occasionally it's let me resuscitate a drive long enough to save some data. Good luck on getting your data back; the lady I was helping didn't have any. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] Tiki Technologies Lead Programmer/Software Architect Did you ever fly a kite in bed? Did you ever walk with ten cats on your head? Did you ever milk this kind of cow? Well we can do it. We know how. If you never did, you should. These things are fun, and fun is good. -- Dr. Seuss ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: off topic - disk crash
Clifton Royston <[EMAIL PROTECTED]> writes: > > Today an important (no backup of course) 46 GB IBM Deskstar > > IDE disk crashed. > This specific line of drives is infamous for a failure rate that's at > least a full order of magnitude above the industry average for ATA > drives. Google a bit for it. Not the entire DeskStar line, just the 75GXP series. I still have several 16Gs and at least one 60GXP that have never given me any trouble, and they were fast and silent for their time, head and shoulders ahead of the competition. These days I mostly buy WD... > > The disk boots into FreeBSD but already at power on time the disk does > > seek retries or some recalibration noise. Also known as the "click of death"... DES -- Dag-Erling SmÃrgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: off topic - disk crash
On Fri, Mar 12, 2004 at 03:58:16PM +0100, Dag-Erling Smørgrav wrote: > Clifton Royston <[EMAIL PROTECTED]> writes: > > > Today an important (no backup of course) 46 GB IBM Deskstar > > > IDE disk crashed. > > This specific line of drives is infamous for a failure rate that's at > > least a full order of magnitude above the industry average for ATA > > drives. Google a bit for it. > > Not the entire DeskStar line, just the 75GXP series. I still have > several 16Gs and at least one 60GXP that have never given me any > trouble, and they were fast and silent for their time, head and > shoulders ahead of the competition. These days I mostly buy WD... > > > > The disk boots into FreeBSD but already at power on time the disk does > > > seek retries or some recalibration noise. > > Also known as the "click of death"... Thanks for all the helpful tips so far. It is a DLTA 307045 (3.5") Don't know whether this is a 75GXP. I'm getting either these: ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=30583 Which don't stop the dd process. And these, ad2: FAILURE - READ_DMA status=51 error=40 LBA=9156 leading to termination. Also the transfer rate is terribly slow: (80 KB/s) I was able to save 18 MB (of 46 GB) (not much so far) Any other suggestions? Could I increase the retry count? Or enforce continuation even in case of hard errors? So that with a bit of luck I could find the FS later in the dump and be able to restore at least partially some files? -- Chris Christoph P. U. Kukulies kuku_at_physik.rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: off topic - disk crash
On Sun, Mar 14, 2004 at 12:25:02PM +0100, Søren Schmidt wrote: > Christoph P. Kukulies wrote: > > >Thanks for all the helpful tips so far. It is a DLTA 307045 (3.5") > >Don't know whether this is a 75GXP. > > It is one of the dreaded models experience shows that all models after > this has some kind of problems, no wonder they sold out :) > > >I'm getting either these: > > > >ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=30583 > > > >Which don't stop the dd process. > > > >And these, > > > >ad2: FAILURE - READ_DMA status=51 > >error=40 LBA=9156 > > > >leading to termination. > > > >Also the transfer rate is terribly slow: (80 KB/s) > > > >I was able to save 18 MB (of 46 GB) (not much so far) > > > >Any other suggestions? > > Use the noerror and sync flags to dd, that will get past errors and put > in NULL sectors for those you cant read. However it will take a looong > time and probably tear off the sorry rests of your magnetic coating on > the platters :( It is now dumping and I'm at 2.7 GB meanwhile. No more errors since the last one at LBA=67 . Are these LBS identical to the block #? Maybe I'll give it another try (when this pass is through) and dump from the beginning. I'm about to get me a second identical model and maybe I then can dd the whole image including partition table so that I will not have to scan the disk for the start of the filesystems. Some time ago I wrote a little program to scan a disk for the start of a FS. Unfortunately that program is also on the crashed disk :-O -- Chris Christoph P. U. Kukulies kuku_at_physik.rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: off topic - disk crash
Christoph P. Kukulies wrote: Thanks for all the helpful tips so far. It is a DLTA 307045 (3.5") Don't know whether this is a 75GXP. It is one of the dreaded models experience shows that all models after this has some kind of problems, no wonder they sold out :) I'm getting either these: ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=30583 Which don't stop the dd process. And these, ad2: FAILURE - READ_DMA status=51 error=40 LBA=9156 leading to termination. Also the transfer rate is terribly slow: (80 KB/s) I was able to save 18 MB (of 46 GB) (not much so far) Any other suggestions? Use the noerror and sync flags to dd, that will get past errors and put in NULL sectors for those you cant read. However it will take a looong time and probably tear off the sorry rests of your magnetic coating on the platters :( -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: off topic - disk crash
Christoph P. Kukulies wrote: It is now dumping and I'm at 2.7 GB meanwhile. No more errors since the last one at LBA=67 . Are these LBS identical to the block #? Yes. Maybe I'll give it another try (when this pass is through) and dump from the beginning. I'm about to get me a second identical model and maybe I then can dd the whole image including partition table so that I will not have to scan the disk for the start of the filesystems. Dont get another DTLA/AVER IBM disk, you will just have the same problem again sometime in the future, stay away from IBM/Hitachi disks that is based on these models (I dont know much about the newer disks from Hitachi and frankly I wont waste my money on them to find out). -- -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: off topic - disk crash
On Sun, Mar 14, 2004 at 01:42:18PM +0100, Søren Schmidt wrote: > Christoph P. Kukulies wrote: > > >the whole image including partition table so that I will not have to > >scan the disk for the start of the filesystems. > > Dont get another DTLA/AVER IBM disk, you will just have the same problem > again sometime in the future, stay away from IBM/Hitachi disks that is > based on these models (I dont know much about the newer disks from > Hitachi and frankly I wont waste my money on them to find out). Yes, I abandoned that idea now since things turn out a bit better. I have built up a recovery system with a new big disk as a FreeBSD 5.2.1 and hooked the troubled disk as in as ad2. I can mount -rf /dev/ad2s1g /mnt and find the old FS with all its entries. I copied over already some very important files and as it seems I will not be as catastrophical as I initially thought. With certain directories or files I get READ_DMA timeouts and also the system hangs totally when a certain type of error occurs. ad2: TIMEOUT - READ_DMA retryinmg (2 retries left) LBA=24703729 ad2: WARNING - READ_DMA Interrupt was seen but but timeout fired LBA=24703729 ad2: WARNING - READ_DMA Interrupt was seen but but taskqueue stalled LBA=24703729 ad0: FAILURE - WRITE_DMA status=51 error=40 LBA=9825063 What I find strange is that the failing drive on the secondary IDE channel causes the primary channel also to fail. I wonder if this has to happen or could be avoided. I can only reboot from that point on. For recovering data this additionally painful and it would be nice I could get this fixed somehow. Another question is whether the read error occurs on the actual data or only during the fstat or directory read. Is it possible to mount a FS with an alternate superblock as information base or do I have to fsck (write back to the disk risking that things get worse) -- Chris Christoph P. U. Kukulies kuku_at_physik.rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: off topic - disk crash
> With certain directories or files I get READ_DMA timeouts and also the > system hangs totally when a certain type of error occurs. > > ad2: TIMEOUT - READ_DMA retryinmg (2 retries left) LBA=24703729 > ad2: WARNING - READ_DMA Interrupt was seen but but timeout fired > LBA=24703729 ad2: WARNING - READ_DMA Interrupt was seen but but taskqueue > stalled LBA=24703729 ad0: FAILURE - WRITE_DMA status=51 > error=40 LBA=9825063 > > What I find strange is that the failing drive on the secondary IDE channel > causes the primary channel also to fail. > > I wonder if this has to happen or could be avoided. I can only reboot from > that point on. I used a straightforward approach: copy files with midc, note on which the system freezes, reboot, and skip those files. Eventually I got everything impotant recovered. BTW, one of the few files which could not be read was the Apache log - another reason to keep huge logs on sepatate drives (or slices, at least). :) Timestamp: 0x4054BCAD [SorAlx] http://cydem.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: off topic - disk crash
> From: "Christoph P. Kukulies" <[EMAIL PROTECTED]> > Subject: Re: off topic - disk crash > To: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=iso-8859-1 > > On Fri, Mar 12, 2004 at 03:58:16PM +0100, Dag-Erling Smørgrav wrote: > > Clifton Royston <[EMAIL PROTECTED]> writes: > > > > Today an important (no backup of course) 46 GB IBM Deskstar > > > > IDE disk crashed. > > > This specific line of drives is infamous for a failure rate that's at > > > least a full order of magnitude above the industry average for ATA > > > drives. Google a bit for it. > > > > Not the entire DeskStar line, just the 75GXP series. I still have > > several 16Gs and at least one 60GXP that have never given me any > > trouble, and they were fast and silent for their time, head and > > shoulders ahead of the competition. These days I mostly buy WD... > > > > > > The disk boots into FreeBSD but already at power on time the disk does > > > > seek retries or some recalibration noise. > > > > Also known as the "click of death"... > > > Thanks for all the helpful tips so far. It is a DLTA 307045 (3.5") > Don't know whether this is a 75GXP. Yes it is. All the 46GB drives for a couple years were, AFAIK, and this particular model (DTLA 307045) is the exact one I was researching and replacing the week before. (BTW, des@ is correct that not all Deskstars are bad; I have a later model Deskstar in my home FreeBSD machine which has been fine. It was the first generation of drives with higher-density platters that have the huge mortality rate.) > I'm getting either these: > > ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=30583 > > Which don't stop the dd process. > > And these, > > ad2: FAILURE - READ_DMA status=51 error=40 > LBA=9156 > > leading to termination. > > Also the transfer rate is terribly slow: (80 KB/s) This is because the drive firmware itself is retrying over and over before it reports errors back up to the controller. > I was able to save 18 MB (of 46 GB) (not much so far) > > Any other suggestions? > > Could I increase the retry count? Or enforce continuation even in case of > hard errors? I see you got responses later on to your other questions on continuing past hard errors; sounds like those are on the right track. If anything, you might want to cut down the driver-level retries, because by the time the failure is returned, the drive itself has already retried exhaustively, but I don't know how you might do that. [merged with following post] > > I'm about to get me a second identical model and maybe I then can dd > > the whole image including partition table so that I will not have to > > scan the disk for the start of the filesystems. > > Dont get another DTLA/AVER IBM disk, you will just have the same problem > again sometime in the future, stay away from IBM/Hitachi disks that is > based on these models (I dont know much about the newer disks from > Hitachi and frankly I wont waste my money on them to find out). If you get the same model/line of DeskStars, you run a high risk of the same problem. Get later models and you're probably OK, but I don't think those include 46GBs. IBM did solve the manufacturing problem, but not before their initial coverups and lies about it had completely ruined a once proud reputation. (BTW, the 18GB Ultrastar SCSI drives from the same period have much the same problem. I've had some of those die in servers within a month or two, whereas I had run many 9.1GB IBM SCSI drives for years of continuous duty without a single failure.) [...] > Another question is whether the read error occurs on the actual data > or only during the fstat or directory read. Is it possible to mount a > FS with an alternate superblock as information base or do I have to fsck > (write back to the disk risking that things get worse) You would want to avoid fscking on the old disk or anything else that would cause writes to it. I don't think there is any way to specify an alternate superblock for a read-only mount (though it would sure be a slick idea if you could.) However, if you succeed in dd'ing the raw partitions off the disk to a new drive, then you can fsck those *copies* of it using an alternate superblock if necessary. I think people were implicitly suggesting that as part of the recovery approach. If you want to be extra sure about recovering everything you possibly can, you would take the partitions you dd-ed from the original disk to a copy on another drive, and treat those as read-only reference copies: rather than fscking them, ma
Re: off topic - disk crash
Christoph P. Kukulies wrote this message on Sun, Mar 14, 2004 at 13:04 +0100: > Some time ago I wrote a little program to scan a disk for the start of > a FS. Unfortunately that program is also on the crashed disk :-O Since you are on 4.8-R you can take a look at ffsrecov. I wrote this program a while back to try to recover data... This program might be able to help you since it will only read minimal amounts of data.. it also will scan for superblocks and report where it believes the begining of the FS is... it also has a mode where you can give it a block number and it will tell you what part of the fs the block is allocated to, be it inode, or data, or free... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
