Date: Tue, 14 Dec 1999 00:49:48 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dkelly@hiwaay.net (David Kelly) Cc: brett@lariat.org, dscheidt@enteract.com, noslenj@swbell.net, tlambert@primenet.com, chat@FreeBSD.ORG Subject: Re: dual 400 -> dual 600 worth it? Message-ID: <199912140049.RAA27931@usr08.primenet.com> In-Reply-To: <199912120047.SAA08385@nospam.hiwaay.net> from "David Kelly" at Dec 11, 99 06:47:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > I sometimes long for the days of ESDI, where the host could control > > EVERYTHING about the way the drive was read and written. (I did > > some experiments which involved positioning the head on a blank track > > when a write was expected, then writing the data to the very next > > sector that came along while simultaneously updating an intention FIFO > > for the metadata on a different spindle. The metadata itself was updated > > later, so the intention log kept things from getting out of sync > > due to power loss. You could pull the plug on that machine when the > > disks were grinding away and never lose a thing.) > > How similar is that to the log partition in SGI's XFS? There was no > restriction as to what spindle the log filesystem was placed. Quite to > the contrary, it was indicated using a separate drive on a separate > SCSI bus would help performance. You can look at the logging code, and find out. SGI has put the logging code up for download as the first installment on XFS. The short answer is that XFS doesn't require a seperate spindle, and unless you turned off write caching most modern drives tend to lie about stuff having been committed to stable storage, and tend to do The Wrong Thing after a power failure, which is they fail to write the data they have in cache before they are done spinning down. A cache that crosses a seek boundary (e.g. for bad sector sparing) is particularly at risk. > XFS for Linux was to be released by now. I haven't been paying > attention. Was it? Right now, it is vapor-ware. They have still not cleaned out the USL code enough to be able to release it. I have heard rumors that they attempted to clean room it, but can't find "virgins" to write the new code that are also capable of doing the job. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912140049.RAA27931>