In fact this behaviour (of mv copying across file systems) is quite new. First showed up in the Linux version of the move command if am not mistaken. The mv command under older Unixes (recalling even SunOS 5.x) never allowed you to move files across file systems.
One problem introduced by this change in semantics is that mv is no longer guaranteed to be atomic: Now if the machine crashes during a move, you could have some of the files on one side and some on the other. Before, this couldn't happen: Either the file had moved or it hadn't, when you finally got the machine back up.


P.



On Monday, Jun 23, 2003, at 15:09 Africa/Kampala, David Ziggy Lubowa wrote:


WHY MV IS SLOW


mv command across filesystems
is slower on large files

WHY?

mv would be slow if you are
moving files across filesystem.

The inode number changes only
when a file is moved across
file system.

A new inode number means a new
file is physically created on
disk.

It remains unchanged, if it
is within the same filesystem.
One can verify by using
ls -il command on that file.

mv uses rename() system call.
if it fails, it uses copy routine
(basicailly reads from a file and
writes in another file).

mv command across filesystem is
more of a copy then mv.



--
David Ziggy Lubowa
Network Engineer
One2net
-----------------------------------
A Network Of People And Technology




Reply via email to