Re: [opensuse] LVM: How to get the PV on which a file is located
Hello
I don't think so, in general. Is it even a meaningful question? i.e. does a file always reside entirely in one PV?
In the VG are 4 PVs. On this server is running a LDAP database since 3 years. But now, after adding an new (large, about 10Gbyte) database, tis new database it is painful slow. I want to know, where are the files located from the both databases. Thanks Meike -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Meike Stone wrote:
Hello
I don't think so, in general. Is it even a meaningful question? i.e. does a file always reside entirely in one PV?
In the VG are 4 PVs. On this server is running a LDAP database since 3 years. But now, after adding an new (large, about 10Gbyte) database, tis new database it is painful slow. I want to know, where are the files located from the both databases.
Thanks Meike
Well the particular blocks that are allocated to each file are going to depend on what type of filesystem the file is created in, and how full and fragmented it is etc. And how they map from blocks in the LV to PVs will depend on when the filesystem was created, and whether it's been extended, and when the PVs were added etc etc. But is it even a single LV? You'd need to tell a lot more about the configuration, I think, before it would be possible to answer your question. I'm not clear why you want to know where the files are located though, if your problem is slow performance. Is it not more likely that there's an I/O bottleneck somewhere? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I'm not clear why you want to know where the files are located though, if your problem is slow performance. Is it not more likely that there's an I/O bottleneck somewhere?
Thats my intention. Because the PV's are located on different SAN discs, there may be a bottleneck in on of them (the storage system). I'm not the admin of this hardware. I must rely on the staff from this department ;-) Now I checked via "dstat", there I can see the physical discs and if I dump a Database, I can see, where the DB is located Meike -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Mon, 22 Apr 2013 16:52:10 +0200
Meike Stone
Hello
I don't think so, in general. Is it even a meaningful question? i.e. does a file always reside entirely in one PV?
In the VG are 4 PVs. On this server is running a LDAP database since 3 years. But now, after adding an new (large, about 10Gbyte) database, tis new database it is painful slow. I want to know, where are the files located from the both databases.
You can use filefrag to get block map for files, LVM commands (see e.g. lvs --segments) to display segment map for LV and put both together ... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Apr 22, 2013 at 10:52 AM, Meike Stone
Hello
I don't think so, in general. Is it even a meaningful question? i.e. does a file always reside entirely in one PV?
In the VG are 4 PVs. On this server is running a LDAP database since 3 years. But now, after adding an new (large, about 10Gbyte) database, tis new database it is painful slow. I want to know, where are the files located from the both databases.
Thanks Meike
You should evaluate iostat -d. I don't have lvm setup on my laptop, but I believe it will show you i/o activity at both the PV level and the LV level so you may be able to correlate which PVs are busy when you are accessing the database. It is in the sysstat package I believe. (sudo zypper in sysstat; iostat -d 10;) There is also tool "xlatencytop". I don't know how to use it effectively, but Linda recommended it a month or two ago for troubleshooting poor disk i/o performance. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Andrey Borzenkov -
Dave Howorth -
Greg Freemyer -
Meike Stone