On Sun, 29 Jul 2001, Greywolf wrote:

> On Sun, 29 Jul 2001, gabriel rosenkoetter wrote:
>
> # Sure, it moves blocks around. So what. Don't use it as your boot
> # disk. You shouldn't be using RAID as your boot disk either, but you
> # sure as hell should be using RAID in certain applications.
> # Alternately, hack either of these file systems to ignore the first X
> # blocks of a disk and put your boot block there. But rather than
> # bitching, how 'bout some code?
>
> 1.  "So what" kind of sidesteps the issue, don't you think?

	As I understand it, LFS moves blocks around as a direct
	consequence of the decision to design for better write performance
	than existing filesystems and keeping read performance also good.

	It would probably not be hard to produce an LFS that did not move
	blocks around - over time both read and to an extent write
	performance would degrade.

	To me moving blocks around is no more a "so what" than the fact
	we run a 64bit capable FFS rather than an older 32bit. Both
	may require (or required) updated boot code.

> 2.  I am *not* bitching, I am observing and evaluating why in the world
>     I would ever want to use LFS in the first place, and it just seemed
>     to me to be a bit frail from all the comments I'd seen on the list.

	Why would anyone ever want to use soft dependencies, cardbus, SMP,
	new platforms, or any other feature still being developed?

	To me LFS is probably a bigger win than SMP, even on a dual box.
	More of my time is spent on IO than CPU.

> 3.  If I could write FS code, I'd have submitted already.  If I can get
>     to a point where I can write FS code and implement a generic journaling
>     layer, you can be sure I will pose it for integration into the tree.

	I'd be interested to see it, but I can't see it outperforming LFS.

> 4.  You have my sincere apology for offending your sensibilities.

	You asked a valid question, your phrasing was just a little
	confrontational.

-- 
		David/absolute		-- www.netbsd.org: No hype required --