cannot remove files: "rm" gives "no space left on device", 3.2.0-24, ubuntu

cannot remove files: "rm" gives "no space left on device", 3.2.0-24, ubuntu

[rupert THURNER]

how would i be able to delete something off this btrfs partition
again? i saw the following messages in the archives which seem to be a
little similar ... except a reboot and therfor a remount did not help:
* http://article.gmane.org/gmane.linux.kernel/1265666/match=enospc

rt@tv:~$ rm -rf /media/388gb-data/.Trash-1000/info/foto.trashinfo
rm: cannot remove `/media/388gb-data/.Trash-1000/info/foto.trashinfo':
No space left on device

rt@tv:~$ btrfs filesystem df /media/388gb-data/
Data: total=260.59GB, used=254.56GB
System: total=32.00MB, used=24.00KB
Metadata: total=128.00GB, used=120.01GB

rt@tv:~$ sudo btrfs filesystem show /dev/sda6
failed to read /dev/sr0
Label: '388gb-data'  uuid: 19223a9e-7840-4798-8ee4-02b5bf9c2899
	Total devices 1 FS bytes used 374.56GB
	devid    1 size 388.62GB used 388.62GB path /dev/sda6

rt@tv:~$ uname -a
Linux tv 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:51:22 UTC 2012
i686 i686 i386 GNU/Linux

the only snapshot is the one created during converting from ext4:
$ sudo btrfs subvolume list /media/388gb-data/
ID 256 top level 5 path ext2_saved


open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=4480528, ...}) = 0
mmap2(NULL, 262144, PROT_READ, MAP_PRIVATE, 3, 0x2bd) = 0xb7553000
mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0x43a) = 0xb7552000
close(3)                                = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
lstat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fstatat64(AT_FDCWD,
"/media/388gb-data/.Trash-1000/info/foto.trashinfo",
{st_mode=S_IFREG|0644, st_size=56, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(AT_FDCWD,
"/media/388gb-data/.Trash-1000/info/foto.trashinfo", 0) = -1 ENOSPC
(No space left on device)
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2570, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7551000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2570
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0xb7551000, 4096)                = 0
open("/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=619, ...}) = 0
mmap2(NULL, 619, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7551000
close(3)                                = 0
write(2, "rm: ", 4rm: )                     = 4
write(2, "cannot remove `/media/388gb-data"..., 65cannot remove
`/media/388gb-data/.Trash-1000/info/foto.trashinfo') = 65
open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/share/locale-langpack/en/LC_MESSAGES/libc.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
write(2, ": No space left on device", 25: No space left on device) = 25
write(2, "\n", 1
)                       = 1
_llseek(0, 0, 0xbfe0d210, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
close(0)                                = 0


rupert

Re: cannot remove files: "rm" gives "no space left on device", 3.2.0-24, ubuntu

[Andrei Popa]

https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21_I_ran_out_of_disk_space.21

On Sat, 2012-06-16 at 13:16 +0200, rupert THURNER wrote:
> how would i be able to delete something off this btrfs partition
> again? i saw the following messages in the archives which seem to be a
> little similar ... except a reboot and therfor a remount did not help:
> * http://article.gmane.org/gmane.linux.kernel/1265666/match=enospc
> 
> rt@tv:~$ rm -rf /media/388gb-data/.Trash-1000/info/foto.trashinfo
> rm: cannot remove `/media/388gb-data/.Trash-1000/info/foto.trashinfo':
> No space left on device
> 
> rt@tv:~$ btrfs filesystem df /media/388gb-data/
> Data: total=260.59GB, used=254.56GB
> System: total=32.00MB, used=24.00KB
> Metadata: total=128.00GB, used=120.01GB
> 
> rt@tv:~$ sudo btrfs filesystem show /dev/sda6
> failed to read /dev/sr0
> Label: '388gb-data'  uuid: 19223a9e-7840-4798-8ee4-02b5bf9c2899
> 	Total devices 1 FS bytes used 374.56GB
> 	devid    1 size 388.62GB used 388.62GB path /dev/sda6
> 
> rt@tv:~$ uname -a
> Linux tv 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:51:22 UTC 2012
> i686 i686 i386 GNU/Linux
> 
> the only snapshot is the one created during converting from ext4:
> $ sudo btrfs subvolume list /media/388gb-data/
> ID 256 top level 5 path ext2_saved
> 
> 
> open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=4480528, ...}) = 0
> mmap2(NULL, 262144, PROT_READ, MAP_PRIVATE, 3, 0x2bd) = 0xb7553000
> mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0x43a) = 0xb7552000
> close(3)                                = 0
> ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
> lstat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> fstatat64(AT_FDCWD,
> "/media/388gb-data/.Trash-1000/info/foto.trashinfo",
> {st_mode=S_IFREG|0644, st_size=56, ...}, AT_SYMLINK_NOFOLLOW) = 0
> unlinkat(AT_FDCWD,
> "/media/388gb-data/.Trash-1000/info/foto.trashinfo", 0) = -1 ENOSPC
> (No space left on device)
> open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=2570, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7551000
> read(3, "# Locale name alias data base.\n#"..., 4096) = 2570
> read(3, "", 4096)                       = 0
> close(3)                                = 0
> munmap(0xb7551000, 4096)                = 0
> open("/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1
> ENOENT (No such file or directory)
> open("/usr/share/locale-langpack/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=619, ...}) = 0
> mmap2(NULL, 619, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7551000
> close(3)                                = 0
> write(2, "rm: ", 4rm: )                     = 4
> write(2, "cannot remove `/media/388gb-data"..., 65cannot remove
> `/media/388gb-data/.Trash-1000/info/foto.trashinfo') = 65
> open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
> (No such file or directory)
> open("/usr/share/locale-langpack/en/LC_MESSAGES/libc.mo", O_RDONLY) =
> -1 ENOENT (No such file or directory)
> write(2, ": No space left on device", 25: No space left on device) = 25
> write(2, "\n", 1
> )                       = 1
> _llseek(0, 0, 0xbfe0d210, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
> close(0)                                = 0
> 
> 
> 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

Re: cannot remove files: "rm" gives "no space left on device", 3.2.0-24, ubuntu

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 4033 bytes --]

On Sat, Jun 16, 2012 at 02:18:15PM +0300, Andrei Popa wrote:
> 
> https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21_I_ran_out_of_disk_space.21

   Also, please note the top box on

https://btrfs.wiki.kernel.org/index.php/Getting_started

   It may help, or it may not, but it's worth doing anyway.

   Hugo.

> On Sat, 2012-06-16 at 13:16 +0200, rupert THURNER wrote:
> > how would i be able to delete something off this btrfs partition
> > again? i saw the following messages in the archives which seem to be a
> > little similar ... except a reboot and therfor a remount did not help:
> > * http://article.gmane.org/gmane.linux.kernel/1265666/match=enospc
> > 
> > rt@tv:~$ rm -rf /media/388gb-data/.Trash-1000/info/foto.trashinfo
> > rm: cannot remove `/media/388gb-data/.Trash-1000/info/foto.trashinfo':
> > No space left on device
> > 
> > rt@tv:~$ btrfs filesystem df /media/388gb-data/
> > Data: total=260.59GB, used=254.56GB
> > System: total=32.00MB, used=24.00KB
> > Metadata: total=128.00GB, used=120.01GB
> > 
> > rt@tv:~$ sudo btrfs filesystem show /dev/sda6
> > failed to read /dev/sr0
> > Label: '388gb-data'  uuid: 19223a9e-7840-4798-8ee4-02b5bf9c2899
> > 	Total devices 1 FS bytes used 374.56GB
> > 	devid    1 size 388.62GB used 388.62GB path /dev/sda6
> > 
> > rt@tv:~$ uname -a
> > Linux tv 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:51:22 UTC 2012
> > i686 i686 i386 GNU/Linux
> > 
> > the only snapshot is the one created during converting from ext4:
> > $ sudo btrfs subvolume list /media/388gb-data/
> > ID 256 top level 5 path ext2_saved
> > 
> > 
> > open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
> > fstat64(3, {st_mode=S_IFREG|0644, st_size=4480528, ...}) = 0
> > mmap2(NULL, 262144, PROT_READ, MAP_PRIVATE, 3, 0x2bd) = 0xb7553000
> > mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0x43a) = 0xb7552000
> > close(3)                                = 0
> > ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
> > lstat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> > fstatat64(AT_FDCWD,
> > "/media/388gb-data/.Trash-1000/info/foto.trashinfo",
> > {st_mode=S_IFREG|0644, st_size=56, ...}, AT_SYMLINK_NOFOLLOW) = 0
> > unlinkat(AT_FDCWD,
> > "/media/388gb-data/.Trash-1000/info/foto.trashinfo", 0) = -1 ENOSPC
> > (No space left on device)
> > open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
> > fstat64(3, {st_mode=S_IFREG|0644, st_size=2570, ...}) = 0
> > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> > 0) = 0xb7551000
> > read(3, "# Locale name alias data base.\n#"..., 4096) = 2570
> > read(3, "", 4096)                       = 0
> > close(3)                                = 0
> > munmap(0xb7551000, 4096)                = 0
> > open("/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1
> > ENOENT (No such file or directory)
> > open("/usr/share/locale-langpack/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = 3
> > fstat64(3, {st_mode=S_IFREG|0644, st_size=619, ...}) = 0
> > mmap2(NULL, 619, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7551000
> > close(3)                                = 0
> > write(2, "rm: ", 4rm: )                     = 4
> > write(2, "cannot remove `/media/388gb-data"..., 65cannot remove
> > `/media/388gb-data/.Trash-1000/info/foto.trashinfo') = 65
> > open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
> > (No such file or directory)
> > open("/usr/share/locale-langpack/en/LC_MESSAGES/libc.mo", O_RDONLY) =
> > -1 ENOENT (No such file or directory)
> > write(2, ": No space left on device", 25: No space left on device) = 25
> > write(2, "\n", 1
> > )                       = 1
> > _llseek(0, 0, 0xbfe0d210, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
> > close(0)                                = 0
> > 
> > 
> > rupert

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
             --- No names... I want to remain anomalous. ---             

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: cannot remove files: "rm" gives "no space left on device", 3.2.0-24, ubuntu

[Peter Maloney]

You most likely need to run the "rm" commands as root, so it can use the
reserved space instead of "no space left". When you use "rm" it needs to
COW some metadata, but root should have space for that.


On 06/16/2012 01:26 PM, Hugo Mills wrote:
> On Sat, Jun 16, 2012 at 02:18:15PM +0300, Andrei Popa wrote:
>> https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21_I_ran_out_of_disk_space.21
>    Also, please note the top box on
>
> https://btrfs.wiki.kernel.org/index.php/Getting_started
>
>    It may help, or it may not, but it's worth doing anyway.
>
>    Hugo.
>
>> On Sat, 2012-06-16 at 13:16 +0200, rupert THURNER wrote:
>>> how would i be able to delete something off this btrfs partition
>>> again? i saw the following messages in the archives which seem to be a
>>> little similar ... except a reboot and therfor a remount did not help:
>>> * http://article.gmane.org/gmane.linux.kernel/1265666/match=enospc
>>>
>>> rt@tv:~$ rm -rf /media/388gb-data/.Trash-1000/info/foto.trashinfo
>>> rm: cannot remove `/media/388gb-data/.Trash-1000/info/foto.trashinfo':
>>> No space left on device
>>>
>>> rt@tv:~$ btrfs filesystem df /media/388gb-data/
>>> Data: total=260.59GB, used=254.56GB
>>> System: total=32.00MB, used=24.00KB
>>> Metadata: total=128.00GB, used=120.01GB
>>>
>>> rt@tv:~$ sudo btrfs filesystem show /dev/sda6
>>> failed to read /dev/sr0
>>> Label: '388gb-data'  uuid: 19223a9e-7840-4798-8ee4-02b5bf9c2899
>>> 	Total devices 1 FS bytes used 374.56GB
>>> 	devid    1 size 388.62GB used 388.62GB path /dev/sda6
>>>
>>> rt@tv:~$ uname -a
>>> Linux tv 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:51:22 UTC 2012
>>> i686 i686 i386 GNU/Linux
>>>
>>> the only snapshot is the one created during converting from ext4:
>>> $ sudo btrfs subvolume list /media/388gb-data/
>>> ID 256 top level 5 path ext2_saved
>>>
>>>
>>> open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
>>> fstat64(3, {st_mode=S_IFREG|0644, st_size=4480528, ...}) = 0
>>> mmap2(NULL, 262144, PROT_READ, MAP_PRIVATE, 3, 0x2bd) = 0xb7553000
>>> mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0x43a) = 0xb7552000
>>> close(3)                                = 0
>>> ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
>>> lstat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>>> fstatat64(AT_FDCWD,
>>> "/media/388gb-data/.Trash-1000/info/foto.trashinfo",
>>> {st_mode=S_IFREG|0644, st_size=56, ...}, AT_SYMLINK_NOFOLLOW) = 0
>>> unlinkat(AT_FDCWD,
>>> "/media/388gb-data/.Trash-1000/info/foto.trashinfo", 0) = -1 ENOSPC
>>> (No space left on device)
>>> open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
>>> fstat64(3, {st_mode=S_IFREG|0644, st_size=2570, ...}) = 0
>>> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
>>> 0) = 0xb7551000
>>> read(3, "# Locale name alias data base.\n#"..., 4096) = 2570
>>> read(3, "", 4096)                       = 0
>>> close(3)                                = 0
>>> munmap(0xb7551000, 4096)                = 0
>>> open("/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1
>>> ENOENT (No such file or directory)
>>> open("/usr/share/locale-langpack/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = 3
>>> fstat64(3, {st_mode=S_IFREG|0644, st_size=619, ...}) = 0
>>> mmap2(NULL, 619, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7551000
>>> close(3)                                = 0
>>> write(2, "rm: ", 4rm: )                     = 4
>>> write(2, "cannot remove `/media/388gb-data"..., 65cannot remove
>>> `/media/388gb-data/.Trash-1000/info/foto.trashinfo') = 65
>>> open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
>>> (No such file or directory)
>>> open("/usr/share/locale-langpack/en/LC_MESSAGES/libc.mo", O_RDONLY) =
>>> -1 ENOENT (No such file or directory)
>>> write(2, ": No space left on device", 25: No space left on device) = 25
>>> write(2, "\n", 1
>>> )                       = 1
>>> _llseek(0, 0, 0xbfe0d210, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
>>> close(0)                                = 0
>>>
>>>
>>> rupert

Re: cannot remove files: "rm" gives "no space left on device", 3.2.0-24, ubuntu

[Sergei Trofimovich]

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]

On Sat, 16 Jun 2012 13:16:09 +0200
rupert THURNER <rupert.thurner@gmail.com> wrote:

> how would i be able to delete something off this btrfs partition
> again? i saw the following messages in the archives which seem to be a
> little similar ... except a reboot and therfor a remount did not help:
> * http://article.gmane.org/gmane.linux.kernel/1265666/match=enospc
> 
> rt@tv:~$ rm -rf /media/388gb-data/.Trash-1000/info/foto.trashinfo
> rm: cannot remove `/media/388gb-data/.Trash-1000/info/foto.trashinfo':
> No space left on device
> 
> rt@tv:~$ btrfs filesystem df /media/388gb-data/
> Data: total=260.59GB, used=254.56GB
> System: total=32.00MB, used=24.00KB
> Metadata: total=128.00GB, used=120.01GB

Looks like there is a bit of space.
Try to mount with
    '-onospace_cache,clear_cache,enospc_debug'
and check if it still reports an ENOSPC error.

Will result in anything reported in 'dmesg' output?

-- 

  Sergei

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: cannot remove files: "rm" gives "no space left on device", 3.2.0-24, ubuntu

[rupert THURNER]

On Sat, Jun 16, 2012 at 1:57 PM, Sergei Trofimovich <slyich@gmail.com> wrote:
> On Sat, 16 Jun 2012 13:16:09 +0200
> rupert THURNER <rupert.thurner@gmail.com> wrote:
>
>> how would i be able to delete something off this btrfs partition
>> again? i saw the following messages in the archives which seem to be a
>> little similar ... except a reboot and therfor a remount did not help:
>> * http://article.gmane.org/gmane.linux.kernel/1265666/match=enospc
>>
>> rt@tv:~$ rm -rf /media/388gb-data/.Trash-1000/info/foto.trashinfo
>> rm: cannot remove `/media/388gb-data/.Trash-1000/info/foto.trashinfo':
>> No space left on device
>>
>> rt@tv:~$ btrfs filesystem df /media/388gb-data/
>> Data: total=260.59GB, used=254.56GB
>> System: total=32.00MB, used=24.00KB
>> Metadata: total=128.00GB, used=120.01GB
>
> Looks like there is a bit of space.
> Try to mount with
>    '-onospace_cache,clear_cache,enospc_debug'
> and check if it still reports an ENOSPC error.
still same error.

> 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

Re: cannot remove files: "rm" gives "no space left on device", 3.2.0-24, ubuntu

[rupert THURNER]

On Sat, Jun 16, 2012 at 2:01 PM, rupert THURNER
<rupert.thurner@gmail.com> wrote:
> On Sat, Jun 16, 2012 at 1:57 PM, Sergei Trofimovich <slyich@gmail.com> wrote:
>> On Sat, 16 Jun 2012 13:16:09 +0200
>> rupert THURNER <rupert.thurner@gmail.com> wrote:
>>
>>> how would i be able to delete something off this btrfs partition
>>> again? i saw the following messages in the archives which seem to be a
>>> little similar ... except a reboot and therfor a remount did not help:
>>> * http://article.gmane.org/gmane.linux.kernel/1265666/match=enospc
>>>
>>> rt@tv:~$ rm -rf /media/388gb-data/.Trash-1000/info/foto.trashinfo
>>> rm: cannot remove `/media/388gb-data/.Trash-1000/info/foto.trashinfo':
>>> No space left on device
>>>
>>> rt@tv:~$ btrfs filesystem df /media/388gb-data/
>>> Data: total=260.59GB, used=254.56GB
>>> System: total=32.00MB, used=24.00KB
>>> Metadata: total=128.00GB, used=120.01GB
>>
>> Looks like there is a bit of space.
>> Try to mount with
>>    '-onospace_cache,clear_cache,enospc_debug'
>> and check if it still reports an ENOSPC error.
> still same error.
>
>> 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.

Re: cannot remove files: "rm" gives "no space left on device", 3.2.0-24, ubuntu

[Andrei Popa]

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.

Andrei

Re: cannot remove files: "rm" gives "no space left on device", 3.2.0-24, ubuntu

[rupert THURNER]

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?

rupert.

Re: cannot remove files: "rm" gives "no space left on device", 3.2.0-24, ubuntu

[Mitch Harder]

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?

Re: cannot remove files: "rm" gives "no space left on device", 3.2.0-24, ubuntu

[rupert THURNER]

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?

rupert.

Re: cannot remove files: "rm" gives "no space left on device", 3.2.0-24, ubuntu

[Goffredo Baroncelli]

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
> .
> 

Re: cannot remove files: "rm" gives "no space left on device", 3.2.0-24, ubuntu

[Goffredo Baroncelli]

On 06/18/2012 08:40 AM, rupert THURNER wrote:
> On Mon, Jun 18, 2012 at 7:53 AM, Goffredo Baroncelli <kreijack@libero.it> wrote:
>> On 06/17/2012 09:54 PM, rupert THURNER wrote:
>>> 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
>>>
> .
>>> 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 ?
> 
> 370 files with ~1GB, and 10000 small. 

I am a bit confused: 370 files of about ~1GB is about a total of
300-400GB; instead you reported

>>> root@tv:~# btrfs filesystem df /media/388gb-data
>>> Data: total=260.59GB, used=251.51GB

My idea is that you converted an old ext4 filesystem (about 300-400GB of
data), and also you updated the greatest part of these files.
Updating an ext4 converted file means a lot of copy-on-write (the
original one is still on the disk and unaffected by the change, an I
think that the consumed space it is not showed), and it might justify
the high metadata usage. But this is only a my guess.

How big is the disk ? As empirical rule, all the file-systems work well
when they are used at 50%. I supposed that the disk it is used nearly 100%.

Is it doable to remove the old ext4 image ? Have you a backup ?


> they are in 1600 directories. i
> converted it from ext4 when it was nearly full, removed maybe 20 big
> files and added again 30 big files. i had the feeling that btrfs was
> able to store more big files than ext4, but i did not count the files
> before.
> 
> # du --max-depth=0 videos* | awk '{sum = sum + $1 ; print} END {print sum}'
> ..
> 364315724
> 
> root@tv:/media/388gb-data# du -sh .
> 724G	.
> 
> root@tv:/media/388gb-data# ls -l ext2_saved/
> total 381793680
> -r-------- 1 root root 417276612608 Jan  1  1970 image
> .
> 

Re: cannot remove files: "rm" gives "no space left on device", 3.2.0-24, ubuntu

[Duncan]

Goffredo Baroncelli posted on Mon, 18 Jun 2012 18:47:21 +0200 as
excerpted:

>>> How big was the original ext4 filesystem ?
>> 
>> 370 files with ~1GB, and 10000 small.
> 
> I am a bit confused: 370 files of about ~1GB is about a total of
> 300-400GB; instead you reported
> 
>>>> root@tv:~# btrfs filesystem df /media/388gb-data Data:
>>>> total=260.59GB,
>>>> used=251.51GB

You're probably correct on the COW from the ext4 conversion in this case, 
but just to note, in my copy (not in-place conversion) from reiserfs, I 
had ball-park-similar numbers, in my case because I was using compress on 
the btrfs side, such that the sum of dup-metadata and single data was 
still smaller than the used space on the reiserfs partition from which I 
was copying.  (I had allowed for the dup metadata and created the btrfs 
partitions somewhat larger accordingly, but compression worked enough 
better than expected that total usage was less, even with dup metadata, 
not more.   That was a nice surprise! =:^)

FWIW, that was the 3.4 kernel cycle.  I'm done testing for now, due to 
reiserfs being far better at recovery from the sata resets and graphics 
lockups plaguing me ATM.  (I need new hardware but no $$ for it ATM.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman