Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Jan 2008 01:10:27 +0100
From:      Thomas Vogt <freebsdlists@bsdunix.ch>
To:        Bill <lists+freebsd-current@xinu.tv>
Cc:        "Julian H. Stacey" <jhs@berklix.org>, freebsd-current@freebsd.org
Subject:   Re: Can't delete any files on my filled up ZFS pool
Message-ID:  <47953473.9030405@bsdunix.ch>
In-Reply-To: <47952FD6.8030207@xinu.tv>
References:  <479515FF.1010709@bsdunix.ch>	<200801212224.m0LMOoP7072911@fire.js.berklix.net> <47952019.3010309@bsdunix.ch> <479523CF.7020804@xinu.tv> <47952ADB.4060306@bsdunix.ch> <47952FD6.8030207@xinu.tv>

next in thread | previous in thread | raw e-mail | index | archive | help
Hello Bill

Bill wrote:
> Does the delete work now?

Sorry for not mentioning. Yes delete work with 'cat /dev/null > 
input.wav ; rm input.wav'. Simple use of rm didn't work

> 
> In your original post, tank was:
> 
> NAME   USED  AVAIL  REFER  MOUNTPOINT
> tank   109G      0  4.11G  /tank

Before Julians hint with cat /dev/null

> 
> and now:
> 
> NAME         USED  AVAIL  REFER  MOUNTPOINT
> tank         104G  5.70G  4.11G  /tank

After Julians hint.


> Is it possible a process was writing to /wav, filled the disk, you tried 
> your 'rm /tank/input.wav' and then the original process writing to /wav 
> unlinked the file that didn't fit, thus freeing 5.7G?

Unlikely. This pool is only used for storing data. No writing from any 
the system.

> 
> /tank and /wav share the available free space on tank.  If that ends up 
> being the problem, you can set the reservation option on tank to prevent 
> it from happening again.  If it's not that I'm not sure what it could 
> be, I'm just trying to point out 'quirky' behavior from ZFS that's 
> different from UFS and the like, do to its pooling nature.

You're right. Maybe it's better to set reservation for zfs too.

Cheers,
Thomas

> Thomas Vogt wrote:
>> Hello
>>
>> Bill wrote:
>>> Do you have snapshots on the pool?  What is the output from 'zfs list'?
>>> It's possible when you have a snapshot on tank that the delete causes 
>>> a copy-on-write for the snapshot that then doesn't have enough space.
>>
>> I don't use snapshots.
>>
>> zfs list
>> NAME         USED  AVAIL  REFER  MOUNTPOINT
>> tank         104G  5.70G  4.11G  /tank
>> tank/wav    99.5G  5.70G  99.5G  /wav
>>
>> Cheers,
>> Thomas
>>
>>
>>> Thomas Vogt wrote:
>>>> Hello Julian
>>>>
>>>> Julian H. Stacey wrote:
>>>>> Thomas Vogt wrote:
>>>>>> Hello
>>>>>>
>>>>>> I need help. My ZFS sytem is filled up. I can't delete any files.
>>>>>>
>>>>>> root@bert:/tank# rm input.wav
>>>>>> rm: input.wav: No space left on device
>>>>>
>>>>> I know nothing about ZFS :-)  (Well nearly, just reading the ZFS pain
>>>>> on @freebsd lists is enough to scare me off for now ;-) ) But if I
>>>>> was stuck on this, with no ZFS experts to quickly ask, I'd guess & 
>>>>> try:
>>>>>
>>>>>     It needs more space for another Inode, or extended directory
>>>>>     entry, cos its maybe going to create another inode in a
>>>>>     backup/ deleted entity first, so either:
>>>>>
>>>>>     A)
>>>>>     Maybe su ; rm input.wav    # if the concept of extra space 
>>>>> still exists
>>>>>                 # per "tunefs -m" for root as per UFS etc.
>>>>
>>>> I filled it as root. So it does not work
>>>>
>>>>>     Or B)
>>>>>     Perhaps more likely:
>>>>>         truncate existing inode to create some space
>>>>>         before deleting it:
>>>>>             cat /dev/null > input.wav ; rm input.wav
>>>>
>>>> Nice. B) works fine. Thank you.
>>>>
>>>>
>>>>>     Presumably if you filled it as root, B might still empty it.
>>>>>
>>>>> There will doubtless be better ZFS answers, but could be interesting
>>>>> to hear if either of above could work.
>>>>
>>>> I hope there will be a "ZFS" answer :)
>>>>
>>>> Regards,
>>>> Thomas
>>>> _______________________________________________
>>>> freebsd-current@freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>> To unsubscribe, send any mail to 
>>>> "freebsd-current-unsubscribe@freebsd.org"
>>>>
>>>
>>
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47953473.9030405>