On 03/10/2009 03:33 PM, David Lehman wrote:
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.
Thanks for the comments. I'll get to work on revising my patches. I
have some questions on some of the comments, but I'll reply to the
individual messages for those.
Thanks,
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
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
