linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Goffredo Baroncelli <kreijack@libero.it>
To: rupert THURNER <rupert.thurner@gmail.com>
Cc: Mitch Harder <mitch.harder@sabayonlinux.org>,
	ierdnah@gmail.com, Sergei Trofimovich <slyich@gmail.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: cannot remove files: "rm" gives "no space left on device", 3.2.0-24, ubuntu
Date: Mon, 18 Jun 2012 07:53:03 +0200	[thread overview]
Message-ID: <4FDEC23F.3050704@libero.it> (raw)
In-Reply-To: <CAJs9aZ94RcRR9MYC0bT81VfMuURDqA2-R2iiN3=Y_8sz7caHpw@mail.gmail.com>

On 06/17/2012 09:54 PM, rupert THURNER wrote:
> On Sun, Jun 17, 2012 at 3:32 PM, Mitch Harder
> <mitch.harder@sabayonlinux.org> wrote:
>> On Sun, Jun 17, 2012 at 3:04 AM, rupert THURNER
>> <rupert.thurner@gmail.com> wrote:
>>> On Sun, Jun 17, 2012 at 7:19 AM, Andrei Popa <ierdnah@gmail.com> wrote:
>>>> On Sun, 2012-06-17 at 06:14 +0200, rupert THURNER wrote:
>>>>>>> Will result in anything reported in 'dmesg' output?
>>>>>> [ 6431.514454] device label 388gb-data devid 1 transid 1086 /dev/sda6
>>>>>> [ 6431.514969] btrfs: disabling disk space caching
>>>>>> [ 6431.514977] btrfs: force clearing of disk cache
>>>>> tried the same with kernel versions from
>>>>> http://kernel.ubuntu.com/~kernel-ppa/mainline/:
>>>>> * 3.2.20
>>>>> * 3.4.0
>>>>> with version 3.4.0, i could delete one tiny file, but only one. peter
>>>>> mentioned before to run the rm as root. yes, i did that, with all
>>>>> kernel versions, the error was the same all the time.
>>>>
>>>> Have you tried to delete the files with "echo > file" ? This will empty
>>>> the file without requiring a new metadata allocation.
>>>
>>> thanks for the hint! i did with the original kernel, but now i tried
>>> it as root and with the 3.4.0 kernel as well. "no space left on
>>> device". is there a  special kernel version or a special btrfs tool
>>> which allows to remove a file without writing more data?
>>>
>>
>> Have you tried mounting with '-o nodatacow' yet?
> 
> this time i booted with the 3.2.20 kernel, as it seems the newewst.
> root@tv:~# uname -a
> Linux tv 3.2.20-030220-generic #201206102035
> 
> mount '-onospace_cache,clear_cache,enospc_debug,nodatacow'
> /dev/sda6/media/388gb-data/
> 
> dmesg
> [  668.229436] btrfs: fail to dirty inode 12714241 error -28
> [  668.232904] btrfs: fail to dirty inode 22544659 error -28
> [  668.233337] btrfs: fail to dirty inode 22544661 error -28
> [  668.263847] btrfs: fail to dirty inode 256 error -28
> [  693.740732] btrfs: fail to dirty inode 14811391 error -28
> 
> 
> echo > /media/388gb-data/bigfile
> --> worked
> 
> then rm of other big files was working as well. the dirty inode
> messages in dmesg are gone as well after unmount and mount. and the df
> displays the additional free space. that it displays 30% of metadata
> seems strange to me, or it counts the still existing ext4 snapshot
> from the conversion somehow into it?
> 
> root@tv:~# btrfs filesystem df /media/388gb-data
> Data: total=260.59GB, used=251.51GB
> System: total=32.00MB, used=24.00KB
> Metadata: total=128.00GB, used=120.00GB
> 
> i included the "nodatacow" option as workaround on the btrfs wikipage,
> ubuntu, as well:
> https://btrfs.wiki.kernel.org/index.php/Ubuntu_support#Ubuntu_Linux_12.04_.28Precise_Pangolin.29
> 
> what would you recommend to do for "normal" usage? one should not
> always use the "nodatacow" option, isn't it?

No, it shouldn't. On my system

 ghigo@venice:~$ sudo btrfs fi df /
 Data: total=17.01GB, used=12.82GB
 System, DUP: total=40.00MB, used=4.00KB
 System: total=4.00MB, used=0.00
 Metadata, DUP: total=2.00GB, used=813.80MB
 Metadata: total=8.00MB, used=0.00

So the ratio metadata:data it is about 1:20

How many files are stored in your hard disk ? Which is a typical file
size ? If a lot of files are less than 4K, these are stored as metadata.
How big was the original ext4 filesystem ?


> 
> rupert.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> .
> 


  reply	other threads:[~2012-06-18  5:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-16 11:16 cannot remove files: "rm" gives "no space left on device", 3.2.0-24, ubuntu rupert THURNER
2012-06-16 11:18 ` Andrei Popa
2012-06-16 11:26   ` Hugo Mills
2012-06-16 11:46     ` Peter Maloney
2012-06-16 11:57 ` Sergei Trofimovich
2012-06-16 12:01   ` rupert THURNER
2012-06-17  4:14     ` rupert THURNER
2012-06-17  5:19       ` Andrei Popa
2012-06-17  8:04         ` rupert THURNER
2012-06-17 13:32           ` Mitch Harder
2012-06-17 19:54             ` rupert THURNER
2012-06-18  5:53               ` Goffredo Baroncelli [this message]
     [not found]                 ` <CAJs9aZ-GHtO3JsvNqLip9CRXxg_J8RUDM=F7GLfdSqCt-zvB3w@mail.gmail.com>
2012-06-18 16:47                   ` Goffredo Baroncelli
2012-06-18 21:54                     ` Duncan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FDEC23F.3050704@libero.it \
    --to=kreijack@libero.it \
    --cc=ierdnah@gmail.com \
    --cc=kreijack@inwind.it \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=mitch.harder@sabayonlinux.org \
    --cc=rupert.thurner@gmail.com \
    --cc=slyich@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).