Date: Wed, 3 Nov 1999 11:40:24 -0500 (EST) From: Kelly Yancey <kbyanc@posi.net> To: Bernd Walter <ticso@cicely.de> Cc: freebsd-fs@FreeBSD.ORG Subject: Re: feature list journalled fs Message-ID: <Pine.BSF.4.05.9911031032500.26857-100000@kronos.alcnet.com> In-Reply-To: <19991103105333.A89617@cicely7.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 3 Nov 1999, Bernd Walter wrote: > > > > 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. That sounds more like a RAID 5/0 config. While I've never seen a hardware vendor advertise support for such a creature, it should theoretically be possible. However, vinum volumes can only provide mirroring between plexes so it is impossible for vinum to extend a volume composed of RAID 5 plexes via concatenation. On the other hand, I see that Greg has "Extending striped and RAID-5 plexes" on his TODO list for vinum, presumably by [shudder] restriping everything. > > > 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. Sorry, I was thinking about the software in RAID controllers in the same terms as vinum. You are correct, though, that to the OS it appears as a single disk which has been enlarged. The same thing, though, is true with vinum; it should appear simply as though the disk were enlarged (albeit a "virtual disk"). 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. > > > 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. I need to clarify terminology here just for myself, because otherwise we're getting into confusing territory... partition: UNIX-style partitions of which there can be 8 (lettered a-h); exist in the disklabel of a slice. slice: PC-style partitioning of disk space of which there can be 4; exist in the master boot record. vinum doesn't support partitions; I don't know whether it supports slices. Now, if vinum supports slices, then vinum doesn't care what filesystem one puts on it (ie how it is sliced up). In which case, one could use vinum to manage a virtual disk with NTFS on one slice and FFS on another. However, if it does not support slices, which I suspect it doesn't, then then entire volume must be dedicated to a single file system. So arguably, yes, if someone were to extend the size of the virtual disk (presumably by adding physical disks to the plex), it would be reasonable to assume that any existing filesystem should be extended to fill the new space. What I can't figure out is why Greg doesn't support slicing / partitioning the virtual disk (this is really the only thing that prevents it from being 100% transparent in my estimation). With a MBR, vinum could be used to hold any filesystem (ie. NTFS, ext2, or FAT32) or any combination thereof; with a disklabel vinum wouldn't require kludges like newfs -v. > > > 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. > You are saying so that when someone updates the disklabel to specify a larger partition, the hooks would be used to notify the filesystem which could then do the dirty work? You haven't happened to visit the Pacific Northwest recent, perhaps near the town of Redmond, WA? :) Seriously, such hooks would have to be in the kernel, not the disklabel program, in the off chance someone uses a tool other than disklabel to edit the partition table. > > > > 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. > 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. Assuming vinum remains the special case of only allowing one file system on it, it would safe for it to call the filesystem resize routine when it brings the spare on-line. However, personally I would like to see vinum become a true virtual disk, allowing multiple file systems. In which case, I don't see where anything other than userland tools would access this interface. > > 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. > This is nice in theory. The tools should still be there to access the functionality, though. My only question is: how does vinum *know* what you want to do. Clearly, in it's current state, it is easy to determine when to enlarge a filesystem (basically whenever more space available); but you can't *know* when the user wants to shrink the filesystem. Userland tools are the only way for the user to tell you. Kelly -- 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.9911031032500.26857-100000>