On 06/17/2012 09:54 PM, rupert THURNER wrote: > On Sun, Jun 17, 2012 at 3:32 PM, Mitch Harder > <mitch.har...@sabayonlinux.org> wrote: >> On Sun, Jun 17, 2012 at 3:04 AM, rupert THURNER >> <rupert.thur...@gmail.com> wrote: >>> On Sun, Jun 17, 2012 at 7:19 AM, Andrei Popa <ierd...@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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > . > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
