Date: Thu, 5 Mar 1998 18:22:43 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: nate@mt.sri.com (Nate Williams) Cc: eivind@yes.no, nate@mt.sri.com, fs@FreeBSD.ORG Subject: Re: [bouyer@antioche.lip6.fr: bi-endian ffs available] Message-ID: <199803051822.LAA25980@usr06.primenet.com> In-Reply-To: <199803051806.LAA19568@mt.sri.com> from "Nate Williams" at Mar 5, 98 11:06:16 am
next in thread | previous in thread | raw e-mail | index | archive | help
> [ FS for big/little endian switch ] > > > > Not if performance matters to you, which it does to me. > > > > I seem to remember about .5 percent performance loss being mentioned in > > later messages. > > I have a *REALLY* hard time believing that number, because for every > read/write you potentially do byte-swapping. Earlier attempts at such a > thing at I believe Univ. of Utah were on the order of 10-15% if I > remember right. (Which I might not be.) I have a hard time believing that number as well. It would be very tempting (to me) to seperate this out as a layer in an "FS type" based on the swapped magic number. The buffer data would be swapped before the upper level (non-swapped) FS code saw it. This would mean the performance penalty was only paid in the swapped media case, and *no* penalty was paid in the default (normal) case. > Also, it requires you to redo all your FS's in order to take advantage > of it, which therefore makes it of little use to 99% of the poeple, and > it could potentially 'kill' someone if they add it to their kernel. I didn't see where this was necessary. The "fsck -s" is, of course, too dangerous, being unrecoverable without a failure. One potential fix for this would be to take part of the reserved area in fs_sparecon; probably this would be 8 full bytes. 8-(. The progress in conversion would be logged to this area. If the log was 0, then the conversion is complete. Otherwise, it could be resumed. Conversion could be done one-behind, since it only applies to metadata ordering; that is, allocate an additional object of the type and bubble-swap through the conversion. This would result in a crash during conversion being completely recoverable. Anyway... I don't think conversion is a good idea, in any case. If you are going to transport media around, then you want to leave it in the native ordering, whatever that is. If you are going to convert data from one machine to another, you would greatly benefit by rebuilding the FS from a backup, instead. 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-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803051822.LAA25980>