On Tue, 2009-03-10 at 14:35 -1000, David Cantrell wrote: > [For descriptions on the patches in this thread, look for > the line beginning with PATCHES.] > > I've been working on hooking up filesystem and device support > in the new storage code. The number of possibilities seem > endless, but I've broken it down to the following list that I > want to get functional: This looks like it's coming along nicely. Aside from the few nits in my responses to individual patches, I think the whole thing is headed in the right direction. Dave > > - Resize ext3 (and ext2) filesystem on a Linux native > partition. The filesystem will be resized, then the > underlying partition. > > - Resize NTFS filesystem on a PartitionDevice, first the > filesystem then the partition. > > LVM possibilities seem to be open to discussion. As in, what > should (or did) we support. Here's what I have on my list as > possibilities: > > - User can shrink a filesystem on a logical volume. First > the filesystem is resized, then the logical volume, then > the volume group, and finally the physical volume. > > - User can shrink a logical volume. This would imply the > use case above since the filesystem (if it existed) would > have to be resized as well. > > - User can shrink a volume group. Any logical volumes in > the volume group would be proportionately resized based > on the size the user selected for the volume group. > > - User can shrink a physical volume. Similar to above, but > moved to the PV level. Any volume groups below would be > proportionately resized based on the new PV size, and then > LVs would be resized in the same way. > > Some of these ideas seem far out there and I question how useful > they would be to the average user. Sure, we have the technology > to accomplish these tasks, but is it really worth the effort in > anaconda? > > My thoughts on VG and PV resizing were based on thinking, "hey, > maybe the user would like to create new logical volumes in an > already existing volume group and install there, we could move > things around for them." But then I thought about how nasty > that would make the code and the likelihood of a PV or VG resize > operation succeeding would be slim anyway. How many traceback > reports do we want in bugzilla anyway? > > So, out of the LVM possibilities, I would personally like to > restrict it to resizing a filesystem, which would shrink or grow > the underlying logical volume, volume group, and physical volume. > Working at the VG or PV layer seems useless in the installer. > > I think the resize policy in anaconda should be to free up > unallocated space on disks rather than to free up possibly usable > space (as in, space in a volume group). If we do the latter, I > think we'd be asking for trouble. > > But I'm open to suggestions. > > PATCHES > > I'm sending what I have for resizing now, but everyone should know > that it doesn't fully work yet. I'm interested in comments on the > code. > > - Initializing the size for existing filesystems is there for > ext2, ext3, and ntfs formats. I use dumpe2fs and ntfsinfo. > > - The 'Shrink current system' window is hooked up. Depending on > your particular system layout, it may or may not work. Feel > free to try, but I doubt it'll work for you. > > - A resize() method has been added for PartitionDevice to handle > resizing the partition after resizing the DeviceFormat. > _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
