Hmm we don't use snapmirror with this array. Here is the output of the vol options command:

> vol options storage
nosnap=off, nosnapdir=off, minra=off, no_atime_update=off, nvfail=off,
ignore_inconsistent=off, snapmirrored=off, create_ucode=off,
convert_ucode=off, maxdirsize=45875, schedsnapname=ordinal,
fs_size_fixed=off, guarantee=volume(disabled), svo_enable=off,
svo_checksum=off, svo_allow_rman=off, svo_reject_errors=off,
no_i2p=off, fractional_reserve=100, extent=off, try_first=volume_grow,
read_realloc=off, snapshot_clone_dependency=off, dlog_hole_reserve=off,
nbu_archival_snap=off

Checking df from the netapp itself, snapshot space looks ok:

> df -h storage
Filesystem               total       used      avail capacity  Mounted on
/vol/storage/           2745GB     2433GB      123GB      95%  /vol/storage/
/vol/storage/.snapshot      144GB      102GB       41GB      71%  /vol/storage/.snapshot



On 09/27/2013 11:32 AM, tmac wrote:
1. was this *ever* a snapmirror destination? if it was there is a "vol options" command to set fs_fixed_size to off (snapmirror turns it on by default)

2. On the netapp, what does "df -h vol-name" show? are you oversubscribed on snapshots?

3. Are you checking df from a client or the netapp itself? If a client, are you on a qtree with a quota?
--> if so, then you will need to modify the quotas file and then resize the quotas for that volume.


--tmac

Tim McCarthy
Principal Consultant

          

        Clustered ONTAP                                                        Clustered ONTAP
 NCDA ID: XK7R3GEKC1QQ2LVD           RHCE6 110-107-141           NCSIE ID: C14QPHE21FR4YWD4
     Expires: 08 November 2014              Current until Aug 02, 2016         Expires: 08 November 2014



On Fri, Sep 27, 2013 at 11:14 AM, Phil Gardner <phil.gardnerjr@gmail.com> wrote:
I recently attempted to expand a volume on one of our 2240's, but it seems to not have any effect on the free space.

From the random reading I've done, it seems that having volumes and aggregates pushing >90% space utilization is not good in any case. Unfortunately the aggregate that this volume lives on is currently at 96% used (150G free), and the volume that I'm trying grow is at 95% used (124GB free).

I attempted to grow the volume by 100G with the 'vol size +100g $volume_name' command. It took about 30s to come back to the prompt, but it did say that the volume has been resized to 100G larger than what df was showing. However, both df and df -A are not currently showing any change in size.

Am I out of luck here? Is there any way to see a "queue" of things the controller is waiting to run or attempting to run? Feel free to school me on the badness of pushing anything close to 100% usage. This controller is sitting betweeen 70-95% CPU util as well. FWIW, this specific controller is used for VM storage, and I probably have some misalignment going on.

--
_____________________
Phil Gardner
PGP Key ID 0xFECC890C
OTR Fingerprint 6707E9B8 BD6062D3 5010FE8B 36D614E3 D2F80538

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters


-- 
_____________________
Phil Gardner
PGP Key ID 0xFECC890C
OTR Fingerprint 6707E9B8 BD6062D3 5010FE8B 36D614E3 D2F80538