On Tuesday 20 March 2012 10.25.38 Markus Falb wrote: > On 19.3.2012 10:14, Peter Kjellström wrote: > > On Sunday 18 March 2012 19.40.21 Ray Van Dolson wrote: > >> On Sun, Mar 18, 2012 at 08:04:14PM +0100, Markus Falb wrote: > >>> What filesystem? Assuming ext3, this cannot shrunk without unmounting. > >>> I believe the following *should* work for ext3 > >>> > >>> $ umount /home > >>> $ e2fsck -f /dev/vg_web/lv_home > >>> $ resize2fs /dev/vg_web/lv_home 150g > >>> $ lvresize -L 150g /dev/vg_web/lv_home > >>> $ mount /home > >>> > >>> I am not sure how safe it is. Take care! > > > > I'd like to add that it's probably good paranoia not to size the lv down > > too tightly (should it happen to become smaller than the fs then ooops). > > That is, I'd size the lv down to a comfortable margin above the fs size > > (and then size the fs up to the device size). > > Hmm. I did that too a couple of times in the past. > But why? What are the reasons for the paranoia? My reasons grounded in the very severe consequences of getting it wrong (cutting the tail of the filesystem...) and the fact that the two sizes are read, unit converted and interpreted by two completely different tools. Say for example that 1g was interpreted as 1000 * 1 MiB (1024^2) bytes by one tool and the other read 1g == 1 GiB == 1024^3 bytes... It is very common for various tools to booth have different definitions (and on top of that unexpected behaviour, bugs...). Add on top the possibility of alignment behaviour (rounding up to the nearest: file system block, device block, lvm PE, ...). > I did a little experiment > > $ lvcreate -L1g -ntest1 vg00 > $ mkfs.ext3 /dev/vg00/test1 > ... > 131072 inodes, 262144 blocks > ... > $ lvcreate -L2g -ntest2 vg00 > $ mkfs.ext3 /dev/vg00/test2 > $ resize2fs /dev/vg00/test2 1g > resize2fs 1.39 (29-May-2006) > Resizing the filesystem on /dev/vg00/test2 to 262144 (4k) blocks. > The filesystem on /dev/vg00/test2 is now 262144 blocks long. > > The sizes (262144) match! Exactly how it should be :-) ...but would I trust that to be the case on another system the next time when a 2nd resize is so easy? /Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.centos.org/pipermail/centos/attachments/20120320/f1bafaa6/attachment-0005.sig>