There are logically no holes. If you have to take a PE out of service in
the middle you multiple choices:
1. Shrink the filesystem by the size of one PE and exchange
the PE in the middle by the PE got free at the end
(Assuming Grow-/Shrinking always happens at the end, otherwise
you *NEED* PE/LV aware FSes)
2. Replace the PE by another PE in the Volume Group beeing
completely transparent to the Filesystem.
Then you might reorganize PEs online for best contigous performance
egain - Think of - PEdefrag which should be no problem with the current
LVM from Heinz which has already got an ability to move PEs, this
would cost a bit performance to move all PEs but this is the choice
of the Administration and you dont need to unmount/singleuserboot
the system/filesystem even if you want to do this.
> I dont think that this complicates the things. We only need some
> interaction between filesystems and devices. Like the
> filesystem telling the device "I would like you to shrink by 4 GB, tell me
> if you are able to do this" "Could you please shrink now by 4 GB, tell me
> when ready" ...
>
> Life is much more complicated that this, though; usually you don't want
> to add and delete physical disks just at the end of the filesystem, but
> in the middle. That means the filesystem needs to intimately know about
> where the logical volumes are on the disk.
It doesnt matter where you delete PE/Physical Disks. You will always
be able to just replace them transparently, be the PEs getting
free at the end by filesystem shrink or with PEs on other PVs in
the same Volume Group. If you havent got free PEs and a full filesystem
you have problems in all solutions. You are not able to move (meta)data in
the ext3 to other locations, and you wont be able to shrink in this solution.
> There are two choices in this case. The first is to have the filesystem
> intimately aware of where all of the volume boundaries are, thus very
> much complicating the block allocation code --- never mind handling the
> case where part of the inode table is in on the physical disk to be
> removed. The second is to do a *lot* of copying of disk blocks when you
> want to reorganize your physical disks. It simply doesn't scale at the
> large terrabyte size.
>
> BTW: I feel a bit like ext2 is going the Microsoft way of doing
> things. Keep as much as compatibility as possible, and therefor
> accept compromises.
>
> [...]
> There are two main advantages with sticking with the ext2fs filesystem
> design path. The first is robustness --- we can control the relatively
> small parts of the filesystem that need to be changed to add B-tree
> directories, for example, while keeping the rest of the filesystem code
> stable. We don't need to re-invent the rest of the filesystem code.
> The second is an easy upgrade path. We can make it much easier for
> people to upgrade from their existing ext2 filesystem to one which
> supports B-tree directories and extents.
IMHO it is easier to start from the beginning having thought on
these nifty features before, then implement it cleanly. As i found
when i was searching for it after Linux-Kongress was, that there
are many filesystem projects for linux which have nice festures,
and performance tweaks. Id like to just keep compatibility
for newer Linux version to old filesystems (ext2) and begin
with a new stable, feature (overloaded) fs in nextgenrationLinux.
BTW: My dream is an AIX way of life. Booting from Volume groups,
growing and shrinking filesystems as i like, adding
disks to any volume(group) i like and having that flexibility.
Flo
-- Florian.Lohoff@mediaWays.net +49-5241-80-7085 aka flo@mini.gt.owl.de @HOME +49-5241-470566- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu