Skip to contentSkip to conversation

expanded volume

linux-lvm German Staltari 2 participants 5 messages Aug 15, 2006

lore
Share & tools
lore
#0 lore raw

Hi, I've expanded a LV but the disks that I've added to the LV/VG are not being used (the I/Os to this disks are almost null and the old ones still with high I/Os). Is there a way to force I/O to the new disks? Thanks
German

#1 lore raw
Quoted 3 lines · German Staltari

Hi, I've expanded a LV but the disks that I've added to the LV/VG are not being used (the I/Os to this disks are almost null and the old ones still with high I/Os). Is there a way to force I/O to the new disks?

did you resize the filesystem? what filesystem(s) are you using?

Regards,
Paddy

Signature · 1 line
Perl 6 will give you the big knob. -- Larry Wall
#2 lore raw
Quoted 10 lines · paddy
Quoted 2 lines · German Staltari

Hi, I've expanded a LV but the disks that I've added to the LV/VG are not being used (the I/Os to this disks are almost null and the old ones still with high I/Os). Is there a way to force I/O to the new disks?

did you resize the filesystem? what filesystem(s) are you using?

Regards,
Paddy

Yes, the FS was resized. I'm using ext3.
Thanks,
German

#3 lore raw
Quoted 8 lines · German Staltari
Quoted 7 lines · paddy
Quoted 4 lines · German Staltari

Hi, I've expanded a LV but the disks that I've added to the LV/VG are not being used (the I/Os to this disks are almost null and the old ones still with high I/Os). Is there a way to force I/O to the new disks?

Quoted 6 lines
Quoted 5 lines

did you resize the filesystem? what filesystem(s) are you using?

Regards,
Paddy

Yes, the FS was resized. I'm using ext3.

ok. I would think that where on the volume the IO goes is a matter of the block allocation in ext3. I'm not intimately familiar with this, but, IIRC, it is optimised around making files contiguous and keeping the locality of files and directories that are close together in the directory tree close together on disk (sort of).

I would guess that the resize2fs program doesn't move the existing data about, but simply adds more space at the end, at which point the allocation pattern that you had is now fairly lop-sided, and new writes are going to tend to be close to the old ones in a lot of cases.

I'm not sure on what a good solution for your problem is, and you will need to apply your knowledge of what the system is doing, but one suggestion would be to move stuff about to try to get the allocation better spread out on the volume. In order to do that I would think you're going to need to make copies and then delete the originals, rather than just changing a few dirents.

It might be that you could usefully apply some defrag utility. It would depend on whether the defragger is looking at the overall pattern of allocation or just local contiguity. I think there may be such for at least ext2, but I have no experience with any.

Another possibility might be to move LEs from one disk to the other. can pvmove be used to do this ? Was your filesystem formatted with a stripe-size option (and how much does it matter) ?

An amount of hand-waving, I know, but I hope it helps :-)

Regards,
Paddy

Signature · 1 line
Perl 6 will give you the big knob. -- Larry Wall
#4 lore raw
Quoted 4 lines · paddy

Another possibility might be to move LEs from one disk to the other. can pvmove be used to do this ? Was your filesystem formatted with a stripe-size option (and how much does it matter) ?

I'll give that a try. Thanks.
BTW, It's possible to move physical extents online (wihtout unmonting the filesystem)?
What it's faster? copy files at FS level? or move physical extents? (It's a TB FS and would be great to do it as faster as we could) Thanks again
German