Can you access the aggregate like the volume by mounting

[chal_arun]

Hello all,

Can we able to mount the aggregate  like the volume using the mount points and exporting  from the exports file .

If so can  anyone explain with an example

[danielpr]

Hi Arun,

Aggregate is the Physical level grouping of disks. It's not possible to mount it.

If you have a traditional Volume then you can mount it as same as volume.

Thanks

Daniel

[chal_arun]

Thank Daniel

[radek_kubka]

Interesting stuff.

I've never heard of any  'normal' method of mounting an aggregate. However there are aggregate-level snapshots (& default 5% snap reserve), which begs the question - how to actually access / use these snapshots?

If memory servers right, I think it can be leveraged by support guys for data recovery (e.g. when a volume has been 'accidentally' destroyed).

Regards,
Radek

[jb2cool01]

I believe you can boot into maintenance mode and do a vol undestroy in order to bring stuff back from the aggr snapshot.

[radek_kubka]

Good.

So, again - it shows that aggregate is not only a physical, but also a logical, volume-like object.

Hence there is a theoretical possibility of mounting an aggregate...

[jb2cool01]

Just one query......

Why would you want to mount the aggregate? One of the good thngs about Filers (In my eyes) is that they are compartmentalised.

[radek_kubka]

It's a forum, OK?

So we are asking (& possibly answering) all kinds of questions with or (sometimes) without practical value

[jb2cool01]

lol, fair enough

[amiller_1]

The question though is....what would you/could you mount?

I'll grant that the aggregate is a file system (WAFL really.....or maybe just kind of ) but how could you mount it? You'd have to have some way to export it from ONTap as well as mount it (and read it).

So...something I see staying very firmly within the realm of theory...

But....on the practical side, "snap restore" does have a "-A" switch which I believe could be used (very carefully) to roll back an entire aggregate.

[guestsylis]

I have always found aggregate snaps kind of interesting. Apart from the lack of real world (i.e. customer) application.

Suppose I have 4 vols each sporting a healthy snapping behavior, how the heck would a small percentage of aggregate snapshot be enough to hold any snapshot history at all? I would suppose changing blocks inside my vols, thus inside my aggregate would usurp any aggr snap reserve almost instantly...

[radek_kubka]

My (informed) guess:

Aggregate snaps are intelligent enough to kick in when a careless user does something dodgy - like vol destroy. So if the cry for help is quick enough, then even 5% extra space may be enough to preserve all blocks changed in the meantime & eventually allow rolling back the aggregate.

Regards,
Radek

[Sebastian_Goetze]

Just a quick note on the aggr snapshot: 5% of the big aggr might be more than 20% of a 'smaller' volume.

Then, if there's blocks in Volume snapshots, they don't need to be physically copied to be in the aggr snapshot.

IAW Aggr snapshot doesn't really eat up a lot of extra-space since it's sharing lot's of data blocks with (e.g.) volume snapshots.

I assume there's a 256-Bit field similar to the one for the volume snapshots, to keep track of which aggr snapshots a particular data block is in. (can a techie confirm ?)

Then again about mounting:

You need a protocol to mount something. There's no protocol access to aggrs. -> you can't mount/map an Aggr

You CAN use other tools like the CLI, though.

Kinda fun, to revert an aggr with SnapRestore to recover a deleted volume (thereby reverting ALL volumes contained in it, too!!!)

It DOES restore deleted (Volume) SnapShots, BTW, so SnapShot deletions are not 'irrevocable', like it's documented.

But you wouldn't want to revert the whole Aggr just to restore a deleted SnapShot... Too high a price to pay, I think.

Now when are they implementing SVSR (Single Volume SnapRestore   😉 like they have SFSR (SFileSR...) now...?

That would be

(Currently possible if you have enough HW... Copy the Aggregate (aggr copy aggr1 -s snapname), revert the copy, copy the volume, destroy the AggrCopy)

My 2 c

Sebastian

[chal_arun]

Hello all,

I found some info in the Storage management guide which specifies that aggr is  the physical layer . I think Daniel is correct.

Aggregates provide storage to volumes. Aggregates are made up of sets of disks, which Data ONTAP
automatically organizes into one or more RAID groups. Aggregates have one or two plexes, depending
on whether RAID-level mirroring (SyncMirror), is in use.

Volumes are data containers. Clients can access the data in volumes through the access protocols
supported by Data ONTAP. These protocols include Network File System (NFS), Common Internet
File System (CIFS), HyperText Transfer Protocol (HTTP), Web-based Distributed

[glynbowden]

Hi,

You can prove for yourself this is the case by looking at the internal filesystem (and so the filesystem that can potentially be exported). If you set the diag level high this should work:

filer> ls /vol/<volname>

qtree1

qtree2

So there is a /vol in the internal filesystem that can be exposed. However, there is no equivalent /aggr as that sits below the logical layer and doesn't have a filesystem as such. (OK, it has WAFL, but it doesn't have the same INODE metadata etc).

So the answer is that aggr's can't be mounted as they aren't real filesystems as ONTAP see's it. Just a pool of raw disk.

Hope that helps clarify a little.

Glyn

[chal_arun]

thanks glyn

[chal_arun]

Hello all,

Still there is a confusion. Donot know whether this discussion is valid or not but still want to  go ahead with my doubts.

If we go with the discussion "Aggr cannot be mounted as volume with a mount point " then

If we create a traditional volume ,  which is same as the aggregate, we are able to mount it as volume and can able to write into it .

Please clarify

mount point

===========

sim:/vol/trad_vol_aggr
                      1.5G   96K  1.5G   1% /sim/trad_vol_aggr

File created in the trad_vol or aggr :

==============================

[root@redhatas4 trad_vol_aggr]# pwd
/sim/trad_vol_aggr

[root@redhatas4 trad_vol_aggr]# touch 2
[root@redhatas4 trad_vol_aggr]#
[root@redhatas4 trad_vol_aggr]# ll
total 0
-rw-r--r--  1 root root 0 Aug 11 12:39 1
-rw-r--r--  1 root root 0 Aug 11 12:45 2

[danielpr]

Arun,

As I said above traditional volume are logical and you can mount it as same as Flexible volume. But this is not possible for aggregate.

Thanks;

Daniel

[glynbowden]

Its down to the steps involved in creating and aggr compared to making a vol of any kind. An aggr create will simply bind disks into a plex and let them sit there. OK I'm sure its a little more complicated than that, but you get the idea. With vol create there is the additional step of creating a filesystem, inode table, metadata etc. Its an additional operation. I guess there is no technical reason why an aggr couldn't be converted to a volume, but that isn't the way it works in ONTAP. If you want to mount it, it has to start life as a filesystem, and that means a volume.

Is there something specific you are trying to achieve by mounting the aggr? Maybe there is another solution that could be suggested.

Glyn

[amiller_1]

You've really just got historical changes going on here (which may be causing the confusion).

Originally, NetApp just had traditional volumes -- tradvols were the aggregate layer and volume layer smashed together -- you couldn't separate them.

With ONTap 7G, we gained a layer of abstraction when the aggregate layer and volume layer were separated (with volumes now most properly called "Flexible Volumes" to indicate that they aren't tied directly to the disk). Of course, you can have qtrees inside either tradvols or flexvols for another layer of isolation/flexibility (FlexVols are wonderfully dynamic but there's a place still for qtrees).

Since with ONTap 7G, every volume had to be inside an aggregate, they chose to represent tradvols as essentially being inside a single-volume aggregate -- but that's really just how they're displayed...it's still a tradvol with the volume and aggregate layer smashed together.

TR-3356 from back when ONTap 7G was introduced has a nice overview of this as well.

http://www.netapp.com/us/library/technical-reports/tr-3356.html

Hopefully that helps a bit...

[danielpr]

Well I found a quite old techontap article @ http://partners.netapp.com/go/techontap/matl/versatile-storage.html

The following Snippet talks about the Aggregate:

Enter Data ONTAP 7G, in which NetApp introduces a new concept called aggregates.Aggregates add a layer of abstraction between the physical disks and the volumes. The idea is simple: allocate a certain number of disks  to a big aggregate, which is built on RAID groups just like traditional volumes. However, there is no file system within an aggregate; it is just allocatable space.

Thanks;

Daniel