Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am planning for a resize of a rather large file system hosting an Oracle instance (one of several on the same server). The disk is 4 TB striped over several LUNs, I'm increasing by 1 TB keeping the same stripe width. As we usually use Oracle ASM for databases, I'm not sure how big of an impact the online resize will have on both the database being extended and also the rest of the system.

Are there any rules of thumb on duration and performance impact of a resize2fs on file system of this size?

share|improve this question
1  
Tb or TB? They're different by a factor of 8... –  MDMarra Jul 23 '12 at 15:28
    
Just curious, are you using fdisk to expand the underlying partition, or are you just going to do something like add another physical volume, add it to the volume group, and then extend the logical volume using lvextend? –  nojak Jul 23 '12 at 21:52
    
We use LVM for everything, so I add several PVs into the volume group and then lvextend. This is trivial as it still does not affect the active file system (directly). The online resize could have impact on operations, thus my question. –  martineg Jul 23 '12 at 22:11
add comment

1 Answer 1

As an authoritative answer from the main fsck.ext2/3 developer:

To a first order approximation, it's roughly 1.7 the times of an fsck. Resize2fs requires that you do a freshly checked filesystem, and then resize2fs itself needs to scan through the filesystem to relocate any blocks needed to expand the group descriptor table. It could take less time, but if you want to be absolutely staff, budget for 2 times a full fsck time.

http://sourceforge.net/projects/e2fsprogs/forums/forum/7053/topic/2009143

So given the characteristics of the load, performance impact would be similar to what fsck -n does to your system - you should be able to benchmark that at a time of day when storage is rather quiet without much impact.

share|improve this answer
    
Thanks to our strict ITIL conformance, this resize got delayed severely. Some time ago I did a read-only fsck, which ran for 5 hours, so I planned to run the actual resize overnight in a "quiet" window. However, when I finally did the resize now, it finished in 20 minutes (IO increased insignificantly while running). –  martineg Oct 31 '12 at 16:31
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.