device-mapper is blocking LVM2

[cach0rr0]

[Mike Hunt]

device-mapper is no longer required by lvm2 >= 2.02.45. It is included in lvm2.

[cach0rr0]

[Mike Hunt]

From page 1 - 4th post

[cach0rr0]

[Mike Hunt]

[Exhaust]

[cach0rr0]

make your backups, and take advantage of quickpkg

if things fail miserably, quickpkg can save your arse.

best of luck, let us know how things turn out.

[Mike Hunt]

I doubt if anything could fail miserably, at worse the volume group wont be initialized, and the logical volumes won't be mounted. It's at most a minor nuisance.

You can Display volume groups and logical volumes

[Exhaust]

Hey, thanks everyone for all the help.

It works flawlessly

Thanks
/Fredrik

[Mike Hunt]

Awesome,

[Exhaust]

Hmm, now i only have one more issue to deal with. wich I have had a feeling could have with lvm and/or device-mapper to do....
guess I don't need to adress that in this thread but i will try to ask nontheless

My FTP is mounted on the LVM volume, wich is about 3TB in size spanning 4-5 physical disks. Sometimes, not always when i create a directory via FTP the system freezes for like a minute or two...nothing happens. then it starts working again.
even the console freezes when this happens.

The problem didn't go away with this update
the only thing not updated now is the kernel and the hardware.
Any thoughts?

The FTP server is glftpd btw.

I guess i will open a new thread about this problem elsewhere

**edit** it's 3TB not 3GB as previously stated


thanks
/Fredrik

[cach0rr0]

what file system is it, and how full is the partition?

Not the total disk itself, I mean how much of that 3GB is actually in use?

The more full the file system, in general the worse the write performance you're going to see - this includes directory creation.

Why 3GB? Is this to limit how much space the FTP users can use? If so I'd opt for setting a per-user disk quota, rather than keeping the volume so small.

If all else fails, strace it - stop the daemon through the init script, then sudo -u <ftpdaemonacct> strace /path/to/binary -somestartupargument -anotherstartupargument -etc

when all other options have run out, strace is your best friend

[Exhaust]

[cach0rr0]

haha...i was wondering if you meant 3TB

I don't really have any ideas then - performance degradation as the volume becomes full is normal, but I haven't a clue if that's part of the cause; and doubt it since as you say, the issue remained when it was less full.

[Exhaust]

I will try to find a place to put a new thread about this. Maybe someone has a clue.
I have to do some more testing and see if it's only glftpd who triggers the problem. It's really weird it only affects directories as far as i have seen. i can upload hundreds of files with good speed (20-30MB/s) then when it comes to creating a dir it freezes for a while then continues with the same high speed as before.

glftpd is a rather server old program and not maintained anymore. And i think the install procedure is a bit unconventional. maybe it's a new system/old glftpd issue. though i never heard or found anyone else with the same problem.

thanks
/Fredrik

[Mike Hunt]

[Exhaust]

Opened a new thread about the slow dir creation problem
[url]
https://forums.gentoo.org/viewtopic-t-784787.html
[/url]