Date: Wed, 3 Nov 1999 10:53:33 +0100 From: Bernd Walter <ticso@cicely.de> To: Kelly Yancey <kbyanc@posi.net> Cc: Bernd Walter <ticso@cicely.de>, Rodney <rr@xs4all.nl>, freebsd-fs@FreeBSD.ORG Subject: Re: feature list journalled fs Message-ID: <19991103105333.A89617@cicely7.cicely.de> In-Reply-To: <Pine.BSF.4.05.9911021900030.3164-100000@kronos.alcnet.com> References: <19991103005415.A88044@cicely7.cicely.de> <Pine.BSF.4.05.9911021900030.3164-100000@kronos.alcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 02, 1999 at 07:16:55PM -0500, Kelly Yancey wrote: > On Wed, 3 Nov 1999, Bernd Walter wrote: > > > On Tue, Nov 02, 1999 at 12:35:53PM -0500, Greg Lehey wrote: > > > On Sunday, 31 October 1999 at 12:05:14 +0100, Rodney wrote: > > > > > > > > > > > > hi, > > > > > > > > here's my list of features I'd like to see in a > > > > journalled fs. Have to admit this list is heavily > > > > inspired ( ok , copied ) from the VxFS features, > > > > apart from th buzz words, > > > > some of them make sense, some of them don't > > > > but it should give us some stuff to discus: > > > > [snip] > > > > 6) vinum integration (vague) > > > > > > Vinum is just a virtual disk. As such, any file system should work on > > > it. > > > > > It is more than that - it is a volume manager. > > Maybe you are not clear how far you got beyound the virtual disk. > > It manages disks and can find it's drive properly if they changed devices - > > that's working relay fine that I was able to remove nearly all wire > > configurations for drives and I'm eaven run a volume with only one single > > drive plex - just to get this feature. > > It can (or should be able to) resize a volume and should inform the system > > about. > > I am under the impression that you can only enlarge a vinum volume if it > in a RAID 0 configuration (concatenation). Obviously, it would be very > difficult to enlarge a RAID 1 or RAID 5 configuration as it would require > restriping the data across all disks; I'm not familiar with any product, > hardware or software, that can do this. In case of Striping which is valid for Raid5 and concatenated Raid0 configrations it is not simply possible to do. But think of a Raid5 volume which is extended with concatenating another Raid5 set. This is not doable with vinum - but I'm shure that this won't happen before anyone is using such a feature feature. > Besides the fact that this would be an issue for any RAID controller No. Most Controllers I have seen increases the size of a disk - not a volume. > also. Anyone with a RAID controller can add a new disk to their RAID 0 and > enlarge the virtual disk. Those controllers aren't going to tell you about > the increased disk size any more than vinum does. Beyond that, who is to They don't need, because the partition the fs is on won't increases if the virtual disk is getting bigger. > say that the entire size of the new, enlarged, virtual disk is supposed be > dedicated to FFS. Is it not possible, however unlikely, for a sysadmin to > add disk space to a RAID array and partition it as say FAT32? That's why it may be interesting to add such hooks to disklabel. > > I think what Greg was getting at as far as the file system is concerned, > vinum just looks like a disk. Whatever else vinum may be, to the file > system it just looks like a disk. > > > I have some ideas about how to get FFS resizeable without needing to freeze or > > umount it before and without loosing inodes. > > This is great, but I think that "vinum hooks" are no more needed than > "ccd hooks" or "DPT hooks". User-land tools should allow the administrator > to resize the file system at the administrators discretion. Beyond the > technical issues of providing hooks to automatically extend file systems, > there is the social implication of whether that is what the user wanted. > User-land tools solve both problems. DPT should be obsolete because the don't change the size of a partition. ccd's should be partionioned too and is not that usefull any more compared to vinum. vinum and disklabel are the hooks, but I think vinum is more usefull. Greg already is about to implement spare disk support. What about a kind of spare disk which is scheduled to increase a FS automaticaly if running out of space. Features like this need interaction between the fs and the volumemanager. Of course Hardware Raid's are a point too - but that's more difficult. > > > Vinum is the frontend for managing the size of the volume and it should inform > > the fs driver about any change, because there is no need to manualy call an > > additional tool. > > My point is modifying FFS but that's the same for any fs. > > > > > > No (see above). Forget about vinum, just worry about disks. Vinum will > play nice and pretend to be a disk. In the end you will have a cleaner > solution that plays nice with others too. Everyone will love the fact that > they can extend any disk, at command, either by adding drives to their > vinum config, their hardware RAID array, or finally whiping Windows off > their home system. > I don't want vinum or anything else like this know how to resize a fs, but I want them to be able to call the needed tools automaticaly. Think of decreasing - firt you have to find out how big the new partition will become - then you need to decrease the fs and finaly you have to decrease the volume. 3 Points to do with the possibility to shoot yourself in the foot. If vinum calls the tool and say "the user want this volume to decrease 134Meg Do want is needed so I can do what the user wants" it is easier and less likely to get you in troubles. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de 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?19991103105333.A89617>