LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   mv hanging a Linux Server (https://www.linuxquestions.org/questions/linux-newbie-8/mv-hanging-a-linux-server-752249/)

HeavyStorm 09-02-2009 08:26 PM

mv hanging a Linux Server
 
Hello ppl,

I've searched the web for an answer over this subject but, so far, it's still very strange: a "simple" mv is hanging my Linux.

The details: I currently using a RedHat Linux (client site), hosted off-site, which I access through SSH. As far as I can tell, SSH is the only way the machine is accessed (i.e., no monitors or keyboards).

I have a certain file on this system that weights in 200GB. Every time I issue a mv for this file, from one partition to another (probably one disc to other), the machine hangs. Right now I'm not sure if this means SSH hangs or system hangs, but from what my client has told me, it's full machine hang.

I don't know any reason for this -- mv's aren't suppose to eat many systems resources and, besides time, I can't think of a relation between its size and consumption -- that is, you don't need more processor, RAM, or whatever to move a 200 GB file than to move a 1GB file.

I not a Linux Administrator -- I'm a programmer -- so I don't know if this has something to do with filesystem handler configuration, but I don't think a stable SO such as Linux would allow any configuration to cause hangs.

Yesterday I was told by one of my clients to use "cp" instead of "mv" to move big files -- again, I don't see much difference since mv over different devices or FS should be threated the same way.

Anyone has ever had this problem or has any insights on the subject? My machine is a AMD 64 (although the system is 32 bits) 64 GB RAM and has 16 cores (4x4). I can request more details on the machine spec or Linux versions if necessary, but my guess is that either something is very wrong or the system should not hang, no matter what spec.

Thanks,
Storm

ArfaSmif 09-02-2009 11:50 PM

Maybe this is too simple but, did you check to see that there is enough room on the partition you are moving too?

I would always do a copy first and a delete after success just to be on the safe side.

estabroo 09-03-2009 12:24 AM

I'd agree that something is wrong, a mv across disks is the same as a cp followed by a rm

HeavyStorm 09-03-2009 11:09 AM

Quote:

Originally Posted by estabroo (Post 3667742)
I'd agree that something is wrong, a mv across disks is the same as a cp followed by a rm

Yes, exactly. I've looked at some implementations of mv (although not RedHat's), and found that mv across devices or partitios is implemented as a copy and remove.

Also, I don't do as ArfaSmif said because, as far I can tell, FS operations on Unix are atomic. At least, from my experience, if the "mv" fails, the original file is not removed.

Anyway, I do have enough space on the destination partition. But "just" enough. Maybe it has something to do with file fragmentation? ext fs'es shouldn't fragment very much, but...

KingX 09-03-2009 11:31 AM

What filesystem are you using on the machine you are trying to move the file over to? You should also check the logs and see what errors (if any) were reported. If logging is turned off then turn it on and try moving the file then, that is the best way to see what the problem is.. rather than making assumptions :)

Edit: Check logs on both machines

tredegar 09-03-2009 12:47 PM

Quote:

I have a certain file on this system that weights in 200GB
That's a big file.

Filesystems have maximum file size limits. ext2 on a 32-bit linux system has a limit of 2GB for a single file. VFS is supposed to have raised this limit to 4TB ( http://e2fsprogs.sourceforge.net/ext2intro.html ), but I know little about it.

KingX is right, you should check the filesystem on the external device. You can do this by plugging it in, waiting 30sec, mounting it (or just "opening" it in your GUI) and then telling us the output of the command mount in a terminal.


All times are GMT -5. The time now is 06:43 PM.