Date: Mon, 3 Apr 95 14:33:25 MDT From: terry@cs.weber.edu (Terry Lambert) To: julian@tfs.com (Julian Elischer) Cc: babkin@hq.icb.chel.su, freebsd-hackers@FreeBSD.org Subject: Re: large filesystems/multiple disks Message-ID: <9504032033.AA08476@cs.weber.edu> In-Reply-To: <m0rvfaz-0003wBC@TFS.COM> from "Julian Elischer" at Apr 2, 95 11:26:41 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > This will work with IBM's JFS (obviously) or with a log structured > > > file system, but precious little else. UFS is particularly badly > > > suited to doing this. If you do what SPRITE does and shove all > > I beg to disagreee, but the UFS can easily be extended.. > if you have it over a LVM that can give you extra space, then you can > add additional cylinder groups without too much pain.... > (I believe OSF1 may have this.. I'll have to check my sources) I recently pointed this out in a news posting on porting the NFS v3 code to BSD 4.3 (which someone wanted), but... A Logical Volume Manager requires a more strict adherence to stackability requirements, and the promiscuous knowledge of the underlying VM system in the current UFS means that it's not strictly stackable. Even if you fixed this and the FS had no intrinsic knowledge of underlying storage interfaces, each cylinder group doesn't get it's own superblock, so you would be limited to a log boundry for the superblocks themselves before they could (potentially) collide with an already allocated block. You could relocate colliding blocks, but with clustering, if the block was the first in a cluster, it could get, well, complicated. 8-(. It is possible with a fairly long duration fsck type operation, and I suppose that you could argue it predicated on that. It still would not solve the multiple points of failure arguments, however. Note that a tool of this complexity is what would be required currently to up the number of inodes on a UFS file system without requiring a backup/mkfs/restore. Because of this being the only thing required for such a tool, it is relatively trivial compared to changing a file system size. I have yet to see such a tool outside of single use code in an academic environment. Going further down this track, I could see where it could be minorly useful for a news spool, where you really could care less about corruption destroying the current contents, or for a system where you religiously backed up your data. I guess the main point I had is that it would be a kludge without real file system changes at the same time. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504032033.AA08476>