Re: [linux-lvm] pvscan showing 0 free on all PV's.

[Rickard Olsson <richie@webhackande.se>]

Tracy R Reed wrote:

> Inherently dangerous? Nonsense. It should not be inherently dangerous if
> the resize tool and LVM do their jobs properly. Resizing should be a
> perfectly safe operation when done properly.

While I agree with you on principle, there is an additional element of 
risk inherent in shrinking a filesystem - moving existing data off the 
shrinking part. Interruptions during this phase may severely damage your 
filesystem's structural integrity (and we can't just route more power to 
the structural integrity field yet).

Very early this morning, I even thought of a good, real-life example:

Imagine that the eastern seaboard of the continental US is your LV. Now, 
along comes hurricane Isabel, hell bent on reducing your VG with a PV or 
two. What do you do? You evacuate (lvreduce, pvmove and resize) the data 
to safer ground. During this evacuation, panic and chaos lurks 
underneath the surface at all times. Bits and bytes flee the still 
unseen enemy. You get traffic jams and the buses are filled with ones 
and zeroes. It's almost inevitable that an operation of this magnitude 
may leave behind some dead and wounded, but the alternative is worse and 
that's why we do it.

OK, it all sounded a lot better before I got my first cup of coffee, but 
still. :-)

A transaction-based pvmove and ditto resize_reiserfs (I don't know if it 
already is or if it turns journalling off during a resize) would solve 
this problem, but pvmove is already slow as it is... A pvmove with hooks 
into Reiser4 so it could use R4s fast transactions might however be 
ideal in this particular case. That almost brings me to my wish-list for 
LVM/EVMS/md/R4, but that's a different story.

    / Rickard Olsson,IT-Konsult/
   / Telefon: +46 70 635 01 42/
  / http://www.webhackande.se/