Date: Wed, 3 Nov 1999 18:29:13 +0100 From: Bernd Walter <ticso@cicely.de> To: Kelly Yancey <kbyanc@posi.net> Cc: Bernd Walter <ticso@cicely.de>, freebsd-fs@FreeBSD.ORG Subject: Re: feature list journalled fs Message-ID: <19991103182912.A92011@cicely7.cicely.de> In-Reply-To: <Pine.BSF.4.05.9911031032500.26857-100000@kronos.alcnet.com> References: <19991103105333.A89617@cicely7.cicely.de> <Pine.BSF.4.05.9911031032500.26857-100000@kronos.alcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 03, 1999 at 11:40:24AM -0500, Kelly Yancey wrote: > On Wed, 3 Nov 1999, Bernd Walter wrote: > > 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. That's what I mean. With the Metadisk software on Solaris it is possible to do. > 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. I asume Greg will do the right thing so everyone should be happy. > > 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. To be exact vinum does not create a disk in the usual way. The volume it creates don't get partitioned like the ccd ones. > > 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. I don't see the need for soing that. If you want to have - say a RAID5 volume partitioned you can also create 2 Volumes with one Raid5 plex. The layout on the disk should be the same. > > 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. That's a drive naming thing not the label. Vinum creates an artificial label and you only need to use newfs -v in some cases. I usually name my volumes d0,d1,d2,... and I don't need to use the -v switch. If I remember this right the volume needs to end on 0-9,a-h. The vinum volumes are useable only with an operating system supporting vinum, it is more a fs issue that limits the further use. The partion name may be a point - I never thought about it. > > > > > > 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. That's an option too - but of course anyone should always be able to do everything manualy. > > 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. In my opinion vinum should not remain a special case but a usual. Vinum brings the toolset to manage and handle volumes - why not implementing hooks for the dependencys? > > > 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. You tell vinum to decrease the volume space. Vinum tells the fs-tool that the volume would become smaller with saying how small. The fs-tool asks the user if he want's to do this after some sanity checkings. If the user did not want or the fs decreased successfully vinum decreases the space and if the decreasing fails vinum should refuse to do. The key missing is how to determine which kind of fs you have to handle but that's mostly a definition point. -- 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?19991103182912.A92011>