#Move Qtree to another vol?

1 messages · Page 1 of 1 (latest)

junior saffron
#

Stupid question friday time! Is it possible to move a NFS qtree from vol 1 to vol2 for an example?

lime finch
#

not within ONTAP. But there are various workarounds

  • if you want to move it to a completely new (empty) volume, use a vol clone and delete everything but the qtree
  • use ndmpcopy
  • use client-side copy (rsync/robocopy)

Sadly, QTree SnapMirror no longer exists in cDOT 😉

tough yacht
#

try XCP, much faster and also will be able to retain the permissions structure as is. It is a simple install (and you get free license)

lime finch
#

Also a good option, but a bit more complicated to set up especially for CIFS. btw, ndmpcopy and robocopy/rsync will also keep permissions intact

tough yacht
#

true, for CIFS is a bit more complicated and also hangs. But for nfs works like a charm.!

frail thicket
#

if only the powers that be would bring back QSM. This was a critical tool for our workflow.

junior saffron
#

I agree, its a real miss

prisma edge
#

One could argue that you could just use volumes/junction-paths instead of qtrees.

I used to say under 7-mode, TMAC’s rule #1 was always use qtrees. Under cdot, it didn’t get a real benefit. In fact, qtree quotas were not even part of the original 8.0 release of clustered ONTAP

junior saffron
#

How would you control giving X team 10GB and Y team 1GB in the same vol?

sick oracle
#

volumes had quota, just not qtrees outsize of the sort of default volume quota possibilities, iirc

#

QSM was a huge PITA and much slower than VSM

prisma edge
#

Right. With ONTAP/cdot there has always been volume quotas. In fact when it first came out people were upset that the qtrees didn’t have quotas like 7-mode

frail thicket
prisma edge
#

Yep

#

I did it all the time way back. I had 4 top level volumes like test/prod/dev/scratch
Those were all 1g volumes. We then had other volumes below each of those and even more volumes under those so something like
/prod/spanish/2012
Were actually three different volumes with the top two being not very big. The volume with the year would be set to read only at the end of each year. If we needed any other junction below it I just made it

sick oracle
#

Been doing the same for years as well... svm_root/admin_vol/user_vols ... the "admin_vol" can be used to set useful administrative rights for inheritence for all underlying user_vols ...

#

even on windows one has the option of mounting luns under "mount point" volumes... saves a lot on "drive letters" for db's and such

frail thicket
#

Awesome, this will solve a number of issues for us. We have volumes over 100TB because they keep adding directories (not even qtrees) at the root level. So we have to use ndmpcopy to move the qtree to another volume.

sick oracle
#

you just need to fix the rights so that they can see read the top level but not create any thing there

frail thicket
#

this worked perfectly. We basically apply perms at the top level. so we are covered. the use case here is when we have to split up date say /foo/a is a folder and has 20TB of data and /foo is already huge, we move all the data into a new volume (foo_a) with ndmpcopy (cuz it's not a qtree 😛 ) then mount it as /foo/a (after renaming the directory a to something else (a_old). now volume foo is 20TB smaller (once we remove a_old) and volume foo_a is 20TB. I just tested this and it worked exactly how I need it to! You just made my weekend.

This all came about from the fact the DFS guys didn't want to use folder in DFS to put shares in (Can't do ABE on a folder, only a share). They only want to point to a single share per dept. so a new share would not work in their world.

prisma edge
#

Another option for something that big to to migrate to using a flexgroup!

frail thicket
#

yeah, flexgroups don't meet the requirement as the volumes are made up of constituents volumes that are block based. I don't think it would allow us to move a qtree or folder around to other volumes. This is required when we need to break up a volume to smaller not grow it bigger with smaller constituents. Basically, we want to keep the volumes smaller so they sync and backup better. What I now need to test is if our backup with snapdiff works. I like this idea cuz now a volume is really treated like a qtree (from a container idea) I can act upon the entire whole data set. I don't think flexgroups allow that? I may be wrong as the only place I am using them today is with tiering.

#

my backup software didn't like it. Opened a ticket with my vendor, hopefully it's a simple fix.

prisma edge
#

Many backup apps, need to specify the exact volume. I know some of the lower end apps have some pretty severe restrictions