YaST Partitioner: is resize2fs finished or not?

Last night I decided to add more disk space to the logical volume where I store my home directories. I had a 500GB SATA drive lying around that came from a non-functional USB enclosure. The disk itself is fine however, verified with badblocks. I wanted to add this drive to my LVM setup and then spread lv_home across both the current and the new disk.

The LVM setup is as follows:

# vgdisplay
  --- Volume group ---
  VG Name               vg_deepthought
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  9
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                4
  Open LV               4
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               931.00 GiB
  PE Size               32.00 MiB
  Total PE              29792
  Alloc PE / Size       29792 / 931.00 GiB
  Free  PE / Size       0 / 0   
  VG UUID               m9yn1h-DeiQ-qB1E-74sj-wGpA-wJG4-UYrkFA

# lvdisplay
  --- Logical volume ---
  LV Path                /dev/vg_deepthought/lv_root
  LV Name                lv_root
  VG Name                vg_deepthought
  LV UUID                yg2bX6-PDEE-qboI-QUog-hFGn-0eKQ-10atdr
  LV Write Access        read/write
  LV Creation host, time , 
  LV Status              available
  # open                 1
  LV Size                40.00 GiB
  Current LE             1280
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0
   
  --- Logical volume ---
  LV Path                /dev/vg_deepthought/lv_home
  LV Name                lv_home
  VG Name                vg_deepthought
  LV UUID                pW82uB-aJvy-vaBJ-MM9v-diiu-RkR4-LW2yGy
  LV Write Access        read/write
  LV Creation host, time , 
  LV Status              available
  # open                 1
  LV Size                875.56 GiB
  Current LE             28018
  Segments               2  <--- this is the new situation, was 1 segment before
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:1
   
  --- Logical volume ---
  LV Path                /dev/vg_deepthought/lv_swap
  LV Name                lv_swap
  VG Name                vg_deepthought
  LV UUID                yI2icc-vIIL-VMaA-3EJC-F8hz-Xj10-ckS5Tc
  LV Write Access        read/write
  LV Creation host, time , 
  LV Status              available
  # open                 1
  LV Size                5.44 GiB
  Current LE             174
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:2
   
  --- Logical volume ---
  LV Path                /dev/vg_deepthought/lv_tmp
  LV Name                lv_tmp
  VG Name                vg_deepthought
  LV UUID                yxuoSK-CAEm-nrsW-INmL-Tkb1-row8-fSwqzX
  LV Write Access        read/write
  LV Creation host, time linux, 2013-05-11 23:24:07 +0200
  LV Status              available
  # open                 1
  LV Size                10.00 GiB
  Current LE             320
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:3

# pvscan 
  PV /dev/sda2   VG vg_deepthought   lvm2 [465.25 GiB / 0    free]
  PV /dev/sdb    VG vg_deepthought   lvm2 [465.75 GiB / 0    free]  <-- the new disk
  Total: 2 [931.00 GiB] / in use: 2 [931.00 GiB] / in no VG: 0 [0   ]

I used the YaST Partitoner tool for this, which warned me that extending the size of the filesytem on lv_home could take a long time while it was mounted. Now, almost 24 hours later, it still sits like this:

http://berisj.home.xs4all.nl/yast.png

As far as I can tell, the LVM setup is stable (see output above) and there is no resize2fs process running, according to ps. Disk space for lv_home has increased accordingly. I tried to figure out what YaST2 has been doing by looking in /var/log/YaST2/y2log but all I see there is this:

013-07-11 23:50:17 <1> barad-dur.site(7923) [libstorage] Storage.cc(waitForDevice):7699 returned prog:/sbin/udevadm settle --timeout=20 retcode:0
2013-07-11 23:50:17 <1> barad-dur.site(7923) [libstorage] Storage.cc(waitForDevice):7709 device:/dev/sdc1 exist:true
2013-07-11 23:50:17 <1> barad-dur.site(7923) [libstorage] Storage.cc(waitForDevice):7723 ret:0
2013-07-11 23:50:17 <1> barad-dur.site(7923) [libstorage] Volume.cc(checkDevice):1489 checkDevice:/dev/sdc1 ret:0
2013-07-11 23:50:17 <1> barad-dur.site(7923) [libstorage] SystemCmd.cc(SystemCmd):55 constructor SystemCmd
2013-07-11 23:50:17 <1> barad-dur.site(7923) [libstorage] Volume.cc(mount):2653 device:/dev/sdc1 mp:/mnt/backup ro:false
2013-07-11 23:50:17 <1> barad-dur.site(7923) [libstorage] Volume.cc(mount):2658 device:/dev/sdc1 mp:/mnt/backup
2013-07-11 23:50:17 <1> barad-dur.site(7923) [libstorage] Volume.cc(mount):2692 l before:<acl user_xattr>
2013-07-11 23:50:17 <1> barad-dur.site(7923) [libstorage] Volume.cc(mount):2698 l  after:<acl user_xattr>
2013-07-11 23:50:17 <1> barad-dur.site(7923) [libstorage] SystemCmd.cc(execute):90 SystemCmd Executing:"/bin/mount -t auto -o acl,user_xattr '/dev/sdc1' '/mnt/backup'"
2013-07-11 23:50:17 <1> barad-dur.site(7923) [libstorage] SystemCmd.cc(addLine):592 Adding Line 1 "NOTE: mount.crypt does not support utab (systems with no mtab or read-only mtab) yet. This means that you will temporarily need to call umount.crypt(8) rather than umount(8) to get crypto volumes unmounted."
2013-07-11 23:50:17 <1> barad-dur.site(7923) [libstorage] SystemCmd.cc(getUntilEOF):558 pid:8095 added lines:1 stderr:true
2013-07-11 23:50:17 <1> barad-dur.site(7923) [libstorage] SystemCmd.cc(addLine):592 Adding Line 1 "Password: "
2013-07-11 23:50:17 <1> barad-dur.site(7923) [libstorage] SystemCmd.cc(getUntilEOF):558 pid:8095 added lines:1 stderr:false

These lines are all from last night, after that, there has been no new messages concerning storage or LVM.

My question now is: do I need to wait longer, is it done or has it failed?

Any disk activity??

I would not think it would take that long but as long as the disk is ticking thing are happening

The resize seems to have finished ok.
But it’s hanging while mounting the LVM.

YaST seems to be waiting for a password for the mount, that’s why it’s hanging I think.
So IMHO you should be save to abort it.

Or maybe you find a Password request hiding somewhere?

On 2013-07-12 21:26, joopberis wrote:
> The disk itself is fine
> however, verified with badblocks.

You have to verify with long SMART test, using smartctl.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

Yes, it seems to hang while mounting /mnt/backup which is a mount point for an external drive, not part of the LVM. It is encrypted, though. There doesn’t seem to be any kind of disk activity, also according to iotop. There’s no hidden password request anywhere, I checked for one on all virtual desktops.

Thanks everyone!

On 2013-07-12 22:56, joopberis wrote:

> @Carlos
> What would SMART be able to tell me about LVM? I thought SMART only
> looks at the physical health of a drive but that it doesn’t care for any
> logical constructs such as partitions, allocation tables and such?

I’m not talking of LVM. You claimed that the disk health was good, and
I’m only addressing that part of your post.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

Yes, I noticed that only after posting, sorry. That’s why I went back and deleted that part out of my post above.

Note to self: don’t post when too sleepy to read.

On 2013-07-12 23:36, joopberis wrote:
>
> robin_listas;2571419 Wrote:

> Yes, I noticed that only after posting, sorry. That’s why I went back
> and deleted that part out of my post above.

Oh. The nntp gateway has played one of its tricks on us. You edited the
post, but it was already sent to nntp users, so I read the original
instead of the modified version. Sigh.

> Note to self: don’t post when too sleepy to read.

It was not your fault, don’t worry.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

Thanks!
Just FYI, the extended SMART test also revealed nothing’s wrong with the disk.

On 2013-07-13 00:56, joopberis wrote:

> Just FYI, the extended SMART test also revealed nothing’s wrong with
> the disk.

Wonderful :slight_smile:

The thing is, the badblocks program can not see bad blocks that have
been remapped byt the disk firmware. You have to look at the
Reallocated_Sector_Ct, Current_Pending_Sector and Offline_Uncorrectable
parameters to find out the truth.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)