https://bugzilla.novell.com/show_bug.cgi?id=749946 https://bugzilla.novell.com/show_bug.cgi?id=749946#c1 kk zhang changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO CC| |kkzhang@novell.com InfoProvider| |bluedzins@wp.pl --- Comment #1 from kk zhang 2012-03-06 08:46:54 UTC --- Please attach y2logs.If you are in doubt follow: http://en.opensuse.org/openSUSE:Bugreport_YaST Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=749946 https://bugzilla.novell.com/show_bug.cgi?id=749946#c kk zhang changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.pr |yast2-maintainers@suse.de |ovo.novell.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=749946 https://bugzilla.novell.com/show_bug.cgi?id=749946#c4 Thomas Fehr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |bluedzins@wp.pl --- Comment #4 from Thomas Fehr 2012-03-12 12:13:40 UTC --- In general there is no problem extending the size of a logical volume with an ext4 filesystem on it while it is mounted. I did that numerous times and it always worked flawlessly. If I am correctly analyzing the y2log files you did the following: You extend the logical volume /dev/dodatkowa/arch from about 2.5 TB to 5.06 TB since YaST2 detected an ext4 fs on the logical volume which is capable of online resizing, YaST2 automatically resizes the filesystem after resizing the logical volume by calling resize2fs. In your case I can see that the resize of the logical volume /dev/dodatkowa/arch to 5.06 TB succeeds. Afterward YaST2 called resize2fs, this apparently creates lots of IO and needs a long time to succeed. I do not see in the y2log file that resizefs exited, so I assume you booted the machine before resize2fs finished. Of course aborting a running resize2fs command most certainly leaves the resized filesystem in an inconsistent state, so this explains that fsck was run later on the logical volume. Unfortunately I do not have 5 Terabyte unused disk space available, but I will try to do such a resize with a 1TB disk and see how much time it needs and how the machine behaves while it is running. Could you look into /var/log/messages if there are kernel error messages at the time you did the resize. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=749946 https://bugzilla.novell.com/show_bug.cgi?id=749946#c6 --- Comment #6 from Thomas Fehr 2012-03-12 17:48:38 UTC --- I did some test meanwhile. I resized a mounted 200Gig volume to 1.3TB (I do not have more free space in one machine currently) and it needed about 80 Minutes so this is consistent with your case needing more than 3 hours. But I saw no heavy IO during resize (iotop showed about 10MB/s while the same volume can do about 100MB/s with dd). So the system was perfectly usable (it even had only 2Gig memory), so I cannot see anything related to a stuck system as you had. I also could use the mounted volume during resize but of course it was quite slow compared to normal speed. To be honest I was not aware of this incredibly slow resize so far. I normally resize my fs quite regularly in chunks of 5 or 10 Gig so there speed and mounted/umounted does not matter much and so far there were no bug reports about this. Why do you think the system needs to copy 2TB of data when resizing from 2.5TB to 5TB? Or did you do this manually while the resize was running? I will do some more tests regarding timing while mounted/umounted. So far I changed the text display during resize, to make the user aware that it may take long and that it must not be aborted. If resizing in umounted state is significantly faster (did not test this yet) and one resizes a mounted fs by a large amount of space I can add a popup that advises the user that resize can be sped up if he umounts the fs. I will not automatically umount in YaST2 resize code since it depends too much from uses cases of the fs if this even possible of if this is harmful or not. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=749946 https://bugzilla.novell.com/show_bug.cgi?id=749946#c8 Thomas Fehr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #8 from Thomas Fehr 2012-03-13 14:19:30 UTC --- Resizing an mounted ext4 fs is more than 10 times slower than resizing a fs not mounted. I added now a warning popup when one resizes by more than 50Gig and the filesystem is mounted. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.