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.