Date: Wed, 3 Nov 1999 16:21:09 -0500 (EST) From: Kelly Yancey <kbyanc@posi.net> To: Greg Lehey <grog@lemis.com> Cc: freebsd-fs@FreeBSD.ORG Subject: Re: feature list journalled fs Message-ID: <Pine.BSF.4.05.9911031515200.49962-100000@kronos.alcnet.com> In-Reply-To: <19991103144037.41321@mojave.sitaranetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 3 Nov 1999, Greg Lehey wrote: > > > No file system should care whether a disk is a "real" disk or a > > "virtual" disk or else a "virtual" disk isn't very virtual. > > Almost correct. It's useful to understand the geometry of a stripe > set when setting up ufs; it's very easy to end up with all cylinder > groups on the same spindle. But wouldn't the apply to any RAID configuration, not just vinum? Albeit difficult to extract such information from any hardware vendor. > > Vinum does support partitions, because there's nothing you can do to > stop it doing so. They just don't make sense in a Vinum context. > I was was mislead by http://www.lemis.com/vinum/Object-naming.html into believing vinum didn't support partitions: "Volumes appear to the system to be identical to disks, with one exception. Unlike UNIX drives, Vinum does not partition volumes, which thus do not contain a partition table. This has required modification to some disk utilities, notably newfs, which previously tried to interpret the last letter of a Vinum volume name as a partition identifier." > Slices are supported too, at least as far as the underlying disk code > is fooled by a Vinum volume. But they don't make sense. Well, I would say that they make sense in the sense the vinum creates a virtual disk which should appear and behave exactly like any physical disk. You can slice up a physical disk and put FFS and NTFS on separate slices. The "don't make sense" part seems to stem from the fact that 99.9% of people don't have any reason to do the OS's associated with the other file systems don't have vinum to access the virtual disk. I've been looking at it as creating something that is indistinquishable from a physical disk drive. In which case, anything a physical disk can do, a vinum disk should do too. The theory being that other tools won't have to adapt then to handle a special case for vinum. And you have done that. Very well. I considered newfs -v a special case, but now I Think Different(tm). :) > It can now. You don't need an MBR, since the bootstrap doesn't > understand Vinum. And the usefulness of ext2 or NTFS file systems is > limited, since Linux and NT don't understand Vinum. The point wasn't so much the "boot" part of the master boot record, but rather the PC-compatible partition table that is stored in the first sector with the MBR. But otherwise, I think we are on the same wavelength. > newfs -v is needed because newfs *without* -v is a kludge. It > shouldn't assume anything from the name of a partition. I see the light. I was thinking about how things are and trying to figure out why vinum didn't emulate the "standard" behaviour. Now I understand that it is simply because the "standard" behaviour is misguided. This makes very good sense. > > Basically what we need is a filesystem-specific resize function which > > userland tools could use a syscall to request a filesystem be resized, and > > the filesystem itself would do the implemention. > > Resizing a file system is not a thing you can do in a system call. > Much needs to be done in user context. Good point. I was thinking along the lines that the filesystem code would be best suited to understand the disk layout, so ideally one would inform the file system that you needed to do some resizing and it would take care of it. Now that I think about it some more, this was ill-conceived, not only would it be unreasonable to put the functionality in the kernel, newfs gives a good precident for userland tools to implement file-system-specific functionality such as resizing. > > > Assuming vinum remains the special case of only allowing one file > > system on it, > > I'd rather hope that this should become the norm. I meant the virtual disk that vinum presents to the world. I guess things for physical disks are like that now, if you regard each wd0s1e as a virtual disk encompassing a subset of the physical disk. In that line of thinking, the slice table is merely a header written to the disk which represents a first level of virtualization; disklabels provide a second level. Looking at things this way, vinum volumes are equivalent to wd0s1e-style volumes. They are both virtual disks (although vinum vastly more configurable :) ), neither necessarily specifies a 1-1 mapping with physical disks, and both can only contain a single file system. I feel enlightened :) Thank you master. > > Greg > -- -- Kelly Yancey - kbyanc@posi.net - Richmond, VA Director of Technical Services, ALC Communications http://www.alcnet.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/ 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?Pine.BSF.4.05.9911031515200.49962-100000>