Date: Mon, 8 Jul 2002 16:51:40 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Peter Wemm <peter@wemm.org> Cc: John Nielsen <hackers@jnielsen.net>, hackers@FreeBSD.ORG Subject: Re: offtopic: low level format of IDE drive. Message-ID: <Pine.BSF.4.21.0207081640510.29644-100000@InterJet.elischer.org> In-Reply-To: <20020708233721.DC2C33808@overcee.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 8 Jul 2002, Peter Wemm wrote: > Julian Elischer wrote: > > this is not a 'reformat' > > > > what I want to do is an old-fashionned refomat/verify where the controller > > writes new track headers etc. > > The thing is, just about all IDE drives more than a few GB or so do > 'track writing' and have no fixed sectoring or sector positioning. > ie: each time you write a single sector to a track, it does a > read-modify-write of *THE ENTIRE TRACK*. This is why we have to have > write caching turned on for IDE drives to get decent performance. > Without it, it essentially rewrites the entire track over and over and > over again because it cannot fill its write buffer in order to write a > contiguous block to completely replace what was there before. ie: > each track is one giant physical sector with multiple logical sectors > inside it. yep I saw that when we were selecting drives for the Interjet. > > The really annoying thing is that most newer scsi drives do this too. Which is what I was trying to say to Terry. :-) > > The sad thing is that this makes softdep almost completely useless, > because the basic assumption is that sectors that were not explicitly > written to will not be touched. The problem is that this isn't the > case, even with write caching turned off. Writing a single sector > causes the drive to completely rebuild the track and all the sectors > on it... in a different relative postition to what was there before. > The resulting power off midwrite can cause an absolute mess in sectors > *adjacent* to where soft updates was carefully writing to. This means > that the 'power off failsafe' file system idea isn't possible with > these drives. The only thing that can deal with this sort of failure > mode is being willing to resort to 'newfs and restore' or a log > structured file system (can you say LFS?). When we asked Kirk to port Soft updates to FreeBSD for the Interjet, we were aware of this.. The original Interjet had a battery in it and could be guaranteed to hold up power for quite a while, (several minutes with a deadish battery even) However when we went to the newer IJ-II teh battery was declared by management top be too expensive. To counter this we spec'd the power supply to have a hold-up time of at least 100mSec after a power failure was detectable. The theory was that a write under way would have time to complete. The Power failure line was directly attached to the systems somewhere (I forget exactly where) wher it could cause an interrupt. On reception of that interrupt, I stuck a long stick into teh workings of the system, freezing everything. According to the specs of the drive it should have noticed the inactivity in the forst few miliseconds and written out the track. Hopefully still within the 100 mSecs. I was considering making it flush the data, but it was unneccesary though I think that for other models of drive it probably would have been useful. > > Get a UPS if you value the data. :-] I don't value the data.. I was looking for a way to reformat! :-) In the end I was able to rewrite the tracks.. apparently only the final parts of the tracks were screwed. > > Back to the topic for a moment.. In theory, dd if=/dev/zero of=disk > bs=64k is as good as it gets for a low level format, on these drive. > With write caching turned on, you are causing every single bit on the > disk to be written to, including the metadata. And the dd > if=/dev/disk of=/dev/null is the read verify. Some drives can have > write verify turned on (I know of certain maxtor models) where the > drive will read back the data and rewrite the entire track if > necessary. that was what I ended up doing.... > > Take the above with a grain of salt, I've never actually worked at a > drive manufacturer. The only thing for sure is that all hard drives > suck. :-) "I'm not an engineer, I just play one on TV"??? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0207081640510.29644-100000>