The problem is that every inode in a qtree has a qtree id in it. You'd have to update the contents of the inode, adjusting the id and updating quotas. Of course, that would be faster (in most cases) than actually copying the data for all files. I'm sure there are other issues, such as the fact that any NFS filehandles referring to the old qtree would be stale, but it's an idea that keeps coming up so I've submitted an RFE for this: 22411.
Mark Muhlestein -- mmm@netapp.com
-----Original Message----- From: Graham C. Knight [mailto:grahamk@ast.lmco.com] Sent: Friday, February 25, 2000 7:38 AM To: toasters@mathworks.com Subject: mv'ing between qtrees
Has anyone figured out a way to trick the system into allowing a lightning fast "mv" of directories/files in between qtrees that are on the same volume?
It seems to me that the filesystem is actually the volume, and that qtree's are just built on top of that - so a "mv" *might* be possible with the right craftiness. Anyone done it? Can anyone tell me beyond a shadow of a doubt that it's impossible so i'll quit trying to figure out a way to do it??
The error i'm trying to work around is this one:
doc*> qtree Volume Tree Style Oplocks -------- -------- ----- -------- vol0 unix enabled vol0 doc-1 mixed enabled vol0 test unix enabled vol0 test2 unix enabled
doc*> mv /test/testing1 /test2 rename: Cross-device link doc*>
Thx, Graham
----- Original Message ----- From: Muhlestein, Mark mark.muhlestein@netapp.com To: 'Graham C. Knight' grahamk@ast.lmco.com; toasters@mathworks.com Sent: Friday, February 25, 2000 9:52 AM Subject: RE: mv'ing between qtrees
The problem is that every inode in a qtree has a qtree id in it. You'd have to update the contents of the inode, adjusting the id and updating quotas. Of course, that would be faster (in most cases) than actually copying the data for all files. I'm sure there are other issues, such as the fact that any NFS filehandles referring to the old qtree would be stale, but it's an idea that keeps coming up so I've submitted an RFE for this: 22411.
This subject came up on the list before and I thought an RFE or somesuch was submitted then, but I could be wrong. I had the same idea... while a mv is problematic it could be faster than a cp if implemented.
Bruce