nope no snap protect. autosize is off on all volumes.
if i move any volume off to another aggregate on another filer, the allocated space ends up matching the used space (well below this 12GB minimum for these nearly empty volumes).
if I move an empty volume from another filer to this aggregate, the allocated space swells up to around this 12GB number. so it seems to be something at the filer or aggregate level.
On Wed, Dec 9, 2015 at 11:52 AM, Tim McCarthy tmacmd@gmail.com wrote:
Were these set up with snap protect?
Check the auto grow settings.
Sent from Mobile Outlook https://aka.ms/qtex0l
On Wed, Dec 9, 2015 at 11:37 AM -0800, "Mike Thompson" < mike.thompson@gmail.com> wrote:
Thanks Andrei - sorry forgot to add to my previous response in the thread,
no dedupe in use.
On Wed, Dec 9, 2015 at 1:26 AM, andrei.borzenkov@ts.fujitsu.com < andrei.borzenkov@ts.fujitsu.com> wrote:
Do you use deduplication by any chance?
With best regards
*Andre**i** Borzenkov*
Senior system engineer
FTS WEMEAI RUC RU SC TMS FOS
[image: cid:image001.gif@01CBF835.B3FEDA90]
*FUJITSU*
Zemlyanoy Val Street, 9, 105 064 Moscow, Russian Federation
Tel.: +7 495 730 62 20 ( reception)
Mob.: +7 916 678 7208
Fax: +7 495 730 62 14
E-mail: Andrei.Borzenkov@ts.fujitsu.com
Web: ru.fujitsu.com http://ts.fujitsu.com/
Company details: ts.fujitsu.com/imprint http://ts.fujitsu.com/imprint.html
This communication contains information that is confidential, proprietary in nature and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) or the person responsible for delivering it to the intended recipient(s), please note that any form of dissemination, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender and delete the original communication. Thank you for your cooperation.
Please be advised that neither Fujitsu, its affiliates, its employees or agents accept liability for any errors, omissions or damages caused by delays of receipt or by any virus infection in this message or its attachments, or which may otherwise arise as a result of this e-mail transmission.
*From:* toasters-bounces@teaparty.net [mailto: toasters-bounces@teaparty.net] *On Behalf Of *Mike Thompson *Sent:* Wednesday, December 09, 2015 11:07 AM *To:* toasters@teaparty.net Lists *Subject:* cdot missing disk space
Hey all,
I've got a cluster running cluster-mode 8.0.5 (don't laugh) that has an aggregate which is reporting much higher used size than I can account for based on the volumes contained on it.
according to 'aggr show' and 'df -A' the aggregate has around 17T of space consumed.
bc-gx-4b::> aggr show -aggregate gx4b_1 -fields size, usedsize, availsize aggregate size usedsize availsize
gx4b_1 18.40TB 17.08TB 1.32TB
though per my database, a tally of all the volumes contained on this aggregate, the total amount of space consumed by the volumes is only about 12.5T of space, so a significant amount is being soaked up by something.
I get the same numbers from the command line as well:
ssh admin@bc-gx-4b "set -units MB; vol show -aggregate gx4b_1 -fields used" | egrep "^bc" | awk '{print $3}' | sed 's/[^0-9]*//g' | paste -sd+ | bc 12528994
so the sum of the volumes is about 12.5T, but the aggregate thinks there is 17T used.
it's been in this state for some time. There haven't been any volumes recently moved off or deleted, so there isn't any space being recovered in the background.
'vol show -state offline' and 'set diag; vol lost-found show' isn't reporting anything.
Any ideas on how I might figure out what is sucking up the un-reported space?
