Chris Murphy posted on Mon, 07 Mar 2016 12:44:20 -0700 as excerpted:
> On Mon, Mar 7, 2016 at 1:42 AM, Marc Haber
> wrote:
>> And this is really something to be proud of? I mean, this is a file
>> system that is part of the vanilla linux kernel, not marked as
>>
Marc Haber posted on Mon, 07 Mar 2016 09:30:43 +0100 as excerpted:
> I have dug aroud in my auth.logs, and thanks to my not working in a root
> shell but using sudo for every single command I can say that the
> filesystem was created on September 1, 2015, so it is not _this_ old,
> and
On Mon, Mar 7, 2016 at 1:42 AM, Marc Haber wrote:
> And this is really something to be proud of? I mean, this is a file
> system that is part of the vanilla linux kernel, not marked as
> experimental or something, and you're still concerned about file
> systems that
On Mon, Mar 07, 2016 at 01:56:54PM -0500, Austin S. Hemmelgarn wrote:
> Yeah, in general, if you want to get good upstream support for BTRFS (such
> as from the mailing lists), you still want to steer clear of 'Enterprise'
> branded distros (RHEL (and by extension CentOS) is particularly bad about
On Mon, Mar 7, 2016 at 11:56 AM, Austin S. Hemmelgarn
wrote:
> People don't often think about it, but given the degree of code and
> version divergence due to patches, RHEL, SLES, and OEL kernels are strictly
> speaking, forks of Linux (most distro kernels are, but usually
On 2016-03-07 13:39, Chris Murphy wrote:
On Mon, Mar 7, 2016 at 1:42 AM, Marc Haber wrote:
[1] Does RHEL 6 have btrfs in the first place?
They do, but you need a decoder ring to figure out what's been
backported to have some vague idea of what equivalent
On Mon, Mar 7, 2016 at 1:42 AM, Marc Haber wrote:
> On Sun, Mar 06, 2016 at 01:27:10PM -0700, Chris Murphy wrote:
>> On the one hand, the practical advice is to just blow it away and use
>> everything current, go back to the same workload including thousands
>> of
On Sat, Mar 05, 2016 at 09:09:09PM +0100, Marc Haber wrote:
> On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
> > So understanding the usage is important to figuring out what's
> > happening. I'd file a bug and include as much information on how the
> > fs got into this state as
On Sun, Mar 06, 2016 at 01:37:31PM -0700, Chris Murphy wrote:
> On Sun, Mar 6, 2016 at 1:27 PM, Chris Murphy wrote:
> > So if it were me, I'd gather all possible data, including complete,
> > not trimmed, logs.
>
> Also include in the bug, the balance script being used.
On Sun, Mar 06, 2016 at 01:27:10PM -0700, Chris Murphy wrote:
> Marc said it was created maybe 2 years ago and doesn't remember what
> version of the tools were used. Between it being two years ago and
> also being Debian, for all we know it could've been 0.19. *shrug*
You are mixing up Debian
On Sun, Mar 06, 2016 at 06:43:46AM +, Duncan wrote:
> Marc Haber posted on Sat, 05 Mar 2016 21:09:09 +0100 as excerpted:
> > On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
> >> Something is happening with the usage of this file system that's out of
> >> the ordinary. This is the
On Sun, Mar 6, 2016 at 1:27 PM, Chris Murphy wrote:
> So if it were me, I'd gather all possible data, including complete,
> not trimmed, logs.
Also include in the bug, the balance script being used. It might be a
contributing factor.
I wonder if the ENOSPC is happening
On Sat, Mar 5, 2016 at 11:43 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Marc Haber posted on Sat, 05 Mar 2016 21:09:09 +0100 as excerpted:
>
>> On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
>
>>> Something is happening with the usage of this file system that's out of
>>> the
Marc Haber posted on Sat, 05 Mar 2016 21:09:09 +0100 as excerpted:
> On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
>> Something is happening with the usage of this file system that's out of
>> the ordinary. This is the first time I've seen such a large amount of
>> unused
On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
> I can't tell what this btrfs-balance script is doing because not every
> btrfs balance command is in the log.
It is. I wrote it to produce reproducible logs.
[1/499]mh@fan:~$ cat btrfs-balance
#!/bin/bash
FS="/mnt/fanbtr"
showdf()
I can't tell what this btrfs-balance script is doing because not every
btrfs balance command is in the log. It may be doing something not
advisable or suboptimal or unexpected that along with some other bug
is causing this to happen
Metadata,DUP: Size:107.00GiB, Used:2.11GiB
I'd try to use
On Thu, Mar 03, 2016 at 02:28:36AM +0200, Dāvis Mosāns wrote:
> I've same issue, 4.4.3 kernel on Arch Linux
>
> $ sudo btrfs fi show /mnt/fs/
> Label: 'fs' uuid: a3c66d25-2c25-40e5-a827-5f7e5208e235
> Total devices 1 FS bytes used 396.94GiB
> devid1 size 435.76GiB used
Hi,
I have not seen this message coming back to the mailing list. Was it
again too long?
I have pastebinned the log at http://paste.debian.net/412118/
On Tue, Mar 01, 2016 at 08:51:32PM +, Duncan wrote:
> There has been something bothering me about this thread that I wasn't
> quite pinning
On Fri, Mar 04, 2016 at 12:31:44PM +, Duncan wrote:
> Dāvis Mosāns posted on Thu, 03 Mar 2016 17:39:12 +0200 as excerpted:
>
> > 2016-03-03 6:57 GMT+02:00 Duncan <1i5t5.dun...@cox.net>:
> >>
> >> You're issue isn't the same, because all your space was allocated,
> >> leaving only 1 MiB
Dāvis Mosāns posted on Thu, 03 Mar 2016 17:39:12 +0200 as excerpted:
> 2016-03-03 6:57 GMT+02:00 Duncan <1i5t5.dun...@cox.net>:
>>
>> You're issue isn't the same, because all your space was allocated,
>> leaving only 1 MiB unallocated, which isn't normally enough to allocate
>> a new chunk to
2016-03-03 6:57 GMT+02:00 Duncan <1i5t5.dun...@cox.net>:
>
> You're issue isn't the same, because all your space was allocated,
> leaving only 1 MiB unallocated, which isn't normally enough to allocate a
> new chunk to rewrite the data or metadata from the old chunks into.
>
> That's a known
Dāvis Mosāns posted on Thu, 03 Mar 2016 02:28:36 +0200 as excerpted:
> 2016-02-27 23:14 GMT+02:00 Marc Haber <mh+linux-bt...@zugschlus.de>:
>> Hi,
>>
>> I have again the issue of no space left on device while rebalancing
>> (with btrfs-tools 4.4.1 on kernel 4.4.2
Dāvis Mosāns wrote on 2016/03/03 02:28 +0200:
2016-02-27 23:14 GMT+02:00 Marc Haber <mh+linux-bt...@zugschlus.de>:
Hi,
I have again the issue of no space left on device while rebalancing
(with btrfs-tools 4.4.1 on kernel 4.4.2 on Debian unstable):
I've same issue, 4.4.3 kernel o
Thanks for the output.
At least for mprofile enospc error, the problem itself is very
straightforward, just unable to alloc tree block.
I'll check the codes to see if we can improve it, by finding out why we
can't alloc a new chunk to resolve the problem.
But I'm still a little concerned
2016-02-27 23:14 GMT+02:00 Marc Haber <mh+linux-bt...@zugschlus.de>:
> Hi,
>
> I have again the issue of no space left on device while rebalancing
> (with btrfs-tools 4.4.1 on kernel 4.4.2 on Debian unstable):
>
I've same issue, 4.4.3 kernel on Arch Linux
$ sudo btrfs fi sho
Qu Wenruo posted on Tue, 01 Mar 2016 15:24:03 +0800 as excerpted:
>
> Marc Haber wrote on 2016/03/01 07:54 +0100:
>> On Tue, Mar 01, 2016 at 08:45:21AM +0800, Qu Wenruo wrote:
>>> Didn't see the attachment though, seems to be filtered by maillist
>>> police.
>>
>> Trying again.
>
> OK, I got
Qu Wenruo wrote on 2016/03/01 15:24 +0800:
Marc Haber wrote on 2016/03/01 07:54 +0100:
On Tue, Mar 01, 2016 at 08:45:21AM +0800, Qu Wenruo wrote:
Didn't see the attachment though, seems to be filtered by maillist
police.
Trying again.
OK, I got the attachment.
And, surprisingly, btrfs
Marc Haber wrote on 2016/03/01 07:54 +0100:
On Tue, Mar 01, 2016 at 08:45:21AM +0800, Qu Wenruo wrote:
Didn't see the attachment though, seems to be filtered by maillist police.
Trying again.
OK, I got the attachment.
And, surprisingly, btrfs balance on data chunk works without problem,
Marc Haber wrote on 2016/02/29 16:33 +0100:
Hi,
On Mon, Feb 29, 2016 at 09:56:58AM +0800, Qu Wenruo wrote:
Marc Haber wrote on 2016/02/27 22:14 +0100:
I have again the issue of no space left on device while rebalancing
(with btrfs-tools 4.4.1 on kernel 4.4.2 on Debian unstable):
mh@fan
Hi,
On Mon, Feb 29, 2016 at 09:56:58AM +0800, Qu Wenruo wrote:
> Marc Haber wrote on 2016/02/27 22:14 +0100:
> >I have again the issue of no space left on device while rebalancing
> >(with btrfs-tools 4.4.1 on kernel 4.4.2 on Debian unstable):
> >
> >mh@fan:~$ sudo btrf
Marc Haber wrote on 2016/02/27 22:14 +0100:
Hi,
I have again the issue of no space left on device while rebalancing
(with btrfs-tools 4.4.1 on kernel 4.4.2 on Debian unstable):
mh@fan:~$ sudo btrfs balance start /mnt/fanbtr
ERROR: error during balancing '/mnt/fanbtr': No space left on device
On Sun, Feb 28, 2016 at 12:22:45AM +, Hugo Mills wrote:
> On Sun, Feb 28, 2016 at 01:08:29AM +0100, Marc Haber wrote:
> > Why wouldn't btrfs allocate more data chunks from the ample free space?
>
>It's a bug. It's been around for years (literally), but nobody's
> tracked it down and fixed
On Sun, Feb 28, 2016 at 01:08:29AM +0100, Marc Haber wrote:
> On Sun, Feb 28, 2016 at 12:15:21AM +0100, Martin Steigerwald wrote:
> > On Samstag, 27. Februar 2016 22:14:50 CET Marc Haber wrote:
> > > I have again the issue of no space left on device while rebalancing
> > &
On Sun, Feb 28, 2016 at 12:15:21AM +0100, Martin Steigerwald wrote:
> On Samstag, 27. Februar 2016 22:14:50 CET Marc Haber wrote:
> > I have again the issue of no space left on device while rebalancing
> > (with btrfs-tools 4.4.1 on kernel 4.4.2 on Debian unstable):
> >
>
On Samstag, 27. Februar 2016 22:14:50 CET Marc Haber wrote:
> Hi,
Hi Marc.
> I have again the issue of no space left on device while rebalancing
> (with btrfs-tools 4.4.1 on kernel 4.4.2 on Debian unstable):
>
> mh@fan:~$ sudo btrfs balance start /mnt/fanbtr
> ERROR: erro
Hi,
I have again the issue of no space left on device while rebalancing
(with btrfs-tools 4.4.1 on kernel 4.4.2 on Debian unstable):
mh@fan:~$ sudo btrfs balance start /mnt/fanbtr
ERROR: error during balancing '/mnt/fanbtr': No space left on device
mh@fan:~$ sudo btrfs fi show /mnt/fanbtr
mh@fan
On Fri, Dec 18, 2015 at 9:38 PM, Christoph Biedl
wrote:
> Henk Slager wrote...
>
>> you need to do some balancing, as I think that the free space is too
>> fragmented and the system fails to allocate extra metadata space
>> needed for scrub doing writes into
led for device id 1: ret=-1, errno=28 (No
> space left on device)
> scrub canceled for 89a02165-5975-46c7-8565-1247874531a2
> scrub started at Fri Dec 18 08:20:27 2015 and was aborted after
> 00:00:01
> total bytes scrubbed: 7.70MiB with 0 errors
>
> btr
Henk Slager wrote...
> you need to do some balancing, as I think that the free space is too
> fragmented and the system fails to allocate extra metadata space
> needed for scrub doing writes into metadata.
>
> # btrfs balance start -dusage=
> with number somewhere between 5 and 50; first start
Hello,
checking all my btr file systems after seeing a lot of trouble on a
particular installation, I came across this:
# btrfs scrub start -B -c3 /mnt/schroot/
ERROR: scrubbing /mnt/schroot/ failed for device id 1: ret=-1, errno=28 (No
space left on device)
scrub canceled for 89a02165-5975
reserve: 16.00MiB (used: 0.00B)
>
> Data,single: Size:8.00MiB, Used:64.00KiB
>/dev/sdb5 8.00MiB
>
> Metadata,DUP: Size:203.75MiB, Used:112.00KiB
>/dev/sdb5 407.50MiB
>
> System,DUP: Size:8.00MiB, Used:16.00KiB
>/dev/sdb5 16.00Mi
ze for partition 3. To me, that sounds like a possible cause
of the errors and 'EiB' reported size.
For RAID tests in VMs I have also been using 4-8GB disk sizes (instead
of TB sized like the real hardware) and I encountered many 'No space
left on device' message (with older kernels).
A quick test with ke
Henk Slager posted on Sun, 08 Nov 2015 19:18:19 +0100 as excerpted:
> [...]
>>3 3145728 4194303 512.0 MiB 8300 Linux filesystem
> [...]
>> root@heisenberg:~# mkfs.btrfs --nodiscard --label boot-data /dev/sdb3
>> btrfs-progs v4.2.2 See http://btrfs.wiki.kernel.org for more
>>
On Sun, 2015-11-08 at 20:39 +, Duncan wrote:
> Wow, yes! Good catch, Henk! =:^) Hugo obviously didn't catch it,
> and I
> wouldn't have either, as the bad size detection behavior is so
> unexpected, it just wouldn't occur to me to look!
Hmm... all that *may* be more likely an error of
Christoph Anton Mitterer posted on Sun, 08 Nov 2015 23:10:57 +0100 as
excerpted:
> On Sun, 2015-11-08 at 20:39 +, Duncan wrote:
>> Wow, yes! Good catch, Henk! =:^) Hugo obviously didn't catch it,
>> and I wouldn't have either, as the bad size detection behavior is so
>> unexpected, it just
Unallocated:
/dev/sdb5 3.56GiB
Still all fine.
Now I write to one of the filesystems (main at first, that still works)
but then when I cp -a from another btrfs to data:
cp: error writing ‘data/SHA512-sums.OLD’: No space left on device
cp: failed to extend ‘data/SHA512-sums.OLD’: No space left
On Sat, 2015-11-07 at 23:30 +, Hugo Mills wrote:
> These are all really small.
Well enough for booting =)
> I would suggest running mkfs with --mixed for all of these
> filesystems and trying again.
I thought btrfs would do that automatically:
Data ratio: 1.00
> Metadata ratio: 2.00
> Global reserve: 16.00MiB (used: 0.00B)
>
> Data,single: Size:8.00MiB, Used:64.00KiB
> /dev/sdb5 8.00MiB
>
> Metadata,DUP: Size:203.75MiB, Used:112.00KiB
>
bogus 'no space left on device' with 'btrfs delete missing' raid5
https://bugzilla.kernel.org/show_bug.cgi?id=104361
Summary: 4x 8GB virtual disks in raid5 with 3.62GiB data, no snapshots
or subvolumes or reflinks; fail one of the devices; reboot; btrfs dev
delete missing fails with 'no space
Still nobody? Upgraded to 4.2-rc2 and i still see the out of space
situation on two 30TB und 40TB arrays every week.
Stefan
Am 27.06.2015 um 17:32 schrieb Stefan Priebe:
Hi,
while having some big btrfs volumes (44TB + 37TB).
I see on a regular basis the no space left on device message. I'm
the no space left on device message.
I'm only
able to fix this. By running btrfs balance AND unmounting and
remounting the btrfs volume.
Is there any way to debug / workaround this one?
You should post your 'df', 'btrfs fi df' and 'btrfs fi show' for
both
On Sat, Jun 27, 2015 at 9:32 AM, Stefan Priebe s.pri...@profihost.ag wrote:
Hi,
while having some big btrfs volumes (44TB + 37TB).
I see on a regular basis the no space left on device message. I'm only
able to fix this. By running btrfs balance AND unmounting and remounting
the btrfs volume
On Sat, 27 Jun 2015 17:32:04 +0200
Stefan Priebe s.pri...@profihost.ag wrote:
Hi,
while having some big btrfs volumes (44TB + 37TB).
I see on a regular basis the no space left on device message. I'm only
able to fix this. By running btrfs balance AND unmounting and
remounting the btrfs
Am 27.06.2015 um 17:51 schrieb Roman Mamedov:
On Sat, 27 Jun 2015 17:32:04 +0200
Stefan Priebe s.pri...@profihost.ag wrote:
Hi,
while having some big btrfs volumes (44TB + 37TB).
I see on a regular basis the no space left on device message. I'm only
able to fix this. By running btrfs balance
Hi,
while having some big btrfs volumes (44TB + 37TB).
I see on a regular basis the no space left on device message. I'm only
able to fix this. By running btrfs balance AND unmounting and
remounting the btrfs volume.
Is there any way to debug / workaround this one?
Greets,
Stefan
On 06/27/2015 10:32 AM, Stefan Priebe wrote:
Hi,
while having some big btrfs volumes (44TB + 37TB).
I see on a regular basis the no space left on device message. I'm
only able to fix this. By running btrfs balance AND unmounting and
remounting the btrfs volume.
Is there any way to debug
; trinity -C 2 -N 10 -V
$D/t3/v1/v2 -qq; echo; echo done; echo; sleep 4; done
mkdir: cannot create directory ‘/mnt/ramdisk/btrfs/t3’: No space left on device
tfoerste@n22kvm-clone ~ $ cd /mnt/ramdisk/btrfs
tfoerste@n22kvm-clone /mnt/ramdisk/btrfs $ ll
total 0
tfoerste@n22kvm-clone /mnt
/April2015-storage-failure/stress-fallocate.sh
Creating 1000 files...
fallocate: test.147: fallocate failed: No space left on device
fallocate: test.148: fallocate failed: No space left on device
fallocate: test.149: fallocate failed: No space left on device
fallocate: test
: test.147: fallocate failed: No space left on device
fallocate: test.148: fallocate failed: No space left on device
fallocate: test.149: fallocate failed: No space left on device
fallocate: test.150: fallocate failed: No space left on device
fallocate: test.151: fallocate failed
/stress-fallocate.sh
Creating 1000 files...
fallocate: test.147: fallocate failed: No space left on device
fallocate: test.148: fallocate failed: No space left on device
fallocate: test.149: fallocate failed: No space left on device
fallocate: test.150: fallocate failed: No space
:
# /root/April2015-storage-failure/stress-fallocate.sh
Creating 1000 files...
fallocate: test.147: fallocate failed: No space left on device
fallocate: test.148: fallocate failed: No space left on device
fallocate: test.149: fallocate failed: No space left on device
; sleep 4; done
After a while I got :
$ sudo rm -rf /mnt/ramdisk/btrfs/t3/
rm: cannot remove ‘/mnt/ramdisk/btrfs/t3/v1/v2/d63’: No space left on device
rm: cannot remove ‘/mnt/ramdisk/btrfs/t3/v1/v2/d10’: No space left on device
rm: cannot remove ‘/mnt/ramdisk/btrfs/t3/v1/v2/f98’: No space left
done
trinity -C 2 -N 10 -V $D/t3/v1/v2 -q
echo
echo done
echo
sleep 4
done
After a while I got :
$ sudo rm -rf /mnt/ramdisk/btrfs/t3/
rm: cannot remove ‘/mnt/ramdisk/btrfs/t3/v1/v2/d63’:
No space left on device
rm: cannot remove ‘/mnt/ramdisk/btrfs
'{}' \;
as indicated in the arch btrfs wiki.
I quickly ran into ENOSPC no space left on device errors which at
first didn't make sense but then, a little later, the obvious occured
to me:
The snapshots were still uncompressed, so the newly compressed data
were allocated separately taking up free space
George Eleftheriou posted on Mon, 07 Apr 2014 12:34:27 +0200 as excerpted:
Browsing the btrfs wiki for a relevant warning I just found this one:
Caveat: Before Linux 3.9, which adds snapshot-aware defragmentation,
defragmenting a file which had a COW copy (either a snapshot copy or one
made
Thank you too for the enlightenment. Not just now but so many times in
the past (just the compilation of your list interventions is a wiki in
its own right).
Me too, I've been meaning to create a wiki account for quite some time
(but I was partly intimidated by the formality of the request :-)
legolas:/mnt/btrfs_pool2# btrfs balance .
ERROR: error during balancing '.' - No space left on device
There may be more info in syslog - try dmesg | tail
[ 8454.159635] BTRFS info (device dm-1): relocating block group 288329039872
flags 1
[ 8590.167294] BTRFS info (device dm-1): relocating block
On Sun, Mar 23, 2014 at 12:01:44AM -0700, Marc MERLIN wrote:
legolas:/mnt/btrfs_pool2# btrfs balance .
ERROR: error during balancing '.' - No space left on device
There may be more info in syslog - try dmesg | tail
[ 8454.159635] BTRFS info (device dm-1): relocating block group 288329039872
Marc MERLIN posted on Sun, 23 Mar 2014 00:01:44 -0700 as excerpted:
legolas:/mnt/btrfs_pool2# btrfs balance .
ERROR: error during balancing '.' - No space left on device
But:
# btrfs fi show `pwd`
Label: btrfs_pool2 uuid: [...]
Total devices 1 FS bytes used 646.41GiB
devid 1
# btrfs balance start -v -dusage=5 /mnt/btrfs_pool2
Dumping filters: flags 0x1, state 0x0, force is off
DATA (flags 0x2): balancing, usage=5
ERROR: error during balancing '/mnt/btrfs_pool2' - No space left on device
But I now just found
https://btrfs.wiki.kernel.org/index.php/Balance_Filters
is off
DATA (flags 0x2): balancing, usage=0
ERROR: error during balancing '/mnt/btrfs_pool2' - No space left on device
Looks like there is no good way out of this, so I'll start deleting
snapshots.
Before you do this, can you take a btrfs-image of your metadata,
and add a report
On Sun, Mar 23, 2014 at 04:28:25PM +, Hugo Mills wrote:
Before you do this, can you take a btrfs-image of your metadata,
and add a report to bugzilla.kernel.org? You're not the only person
who's had this problem recently, and I suspect there's something
still lurking in there that needs
On Sun, Mar 23, 2014 at 10:03:14AM -0700, Marc MERLIN wrote:
On Sun, Mar 23, 2014 at 04:28:25PM +, Hugo Mills wrote:
Before you do this, can you take a btrfs-image of your metadata,
and add a report to bugzilla.kernel.org? You're not the only person
who's had this problem recently,
On Sun, Mar 23, 2014 at 05:34:09PM +, Hugo Mills wrote:
xaba on IRC has just pointed out that it looks like you're running
this on a mounted filesystem -- it needs to be unmounted for
btrfs-image to work reliably.
Sorry, I didn't realize that, although it makes sense. btrfs-image
On Sun, Mar 23, 2014 at 12:10:17PM -0700, Marc MERLIN wrote:
On Sun, Mar 23, 2014 at 05:34:09PM +, Hugo Mills wrote:
xaba on IRC has just pointed out that it looks like you're running
this on a mounted filesystem -- it needs to be unmounted for
btrfs-image to work reliably.
On 25.02.2014 22:30, Josef Bacik wrote:
On 02/25/2014 03:27 PM, Marcus Sundman wrote:
On 25.02.2014 22:19, Hugo Mills wrote:
On Tue, Feb 25, 2014 at 01:05:51PM -0500, Jim Salter wrote:
370GB of 410GB used isn't really fine, it's over 90% usage.
That said, I'd be interested to know why btrfs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/26/2014 07:16 PM, Marcus Sundman wrote:
On 25.02.2014 22:30, Josef Bacik wrote:
On 02/25/2014 03:27 PM, Marcus Sundman wrote:
On 25.02.2014 22:19, Hugo Mills wrote:
On Tue, Feb 25, 2014 at 01:05:51PM -0500, Jim Salter wrote:
370GB of 410GB
On Thu, Feb 27, 2014 at 02:16:07AM +0200, Marcus Sundman wrote:
On 25.02.2014 22:30, Josef Bacik wrote:
On 02/25/2014 03:27 PM, Marcus Sundman wrote:
On 25.02.2014 22:19, Hugo Mills wrote:
On Tue, Feb 25, 2014 at 01:05:51PM -0500, Jim Salter wrote:
370GB of 410GB used isn't really fine, it's
Hi
I get No space left on device and it is unclear why:
# df -h|grep sda3
/dev/sda3 413G 368G 45G 90% /home
# btrfs filesystem show /dev/sda3
Label: 'home' uuid: 46279061-51f4-40c2-afd0-61d6faab7f60
Total devices 1 FS bytes used 371.11GB
devid1 size 412.54GB used
370GB of 410GB used isn't really fine, it's over 90% usage.
That said, I'd be interested to know why btrfs fi show /dev/sda3 shows
412.54G used, but btrfs fi df /home shows 379G used...
On 02/25/2014 11:49 AM, Marcus Sundman wrote:
Hi
I get No space left on device and it is unclear why
actually mean.
On 02/25/2014 11:49 AM, Marcus Sundman wrote:
Hi
I get No space left on device and it is unclear why:
# df -h|grep sda3
/dev/sda3 413G 368G 45G 90% /home
# btrfs filesystem show /dev/sda3
Label: 'home' uuid: 46279061-51f4-40c2-afd0-61d6faab7f60
Total devices 1 FS
. The FS can't allocate more metadata because it's allocated
everything already (total=used in btrfs fi show), so the solution is
to do a filtered balance:
btrfs balance start -dusage=5 /mountpoint
Hugo.
On 02/25/2014 11:49 AM, Marcus Sundman wrote:
Hi
I get No space left on device
, and it didn't help *at* *all*:
# btrfs filesystem balance start -dusage=5 /home
Done, had to relocate 0 out of 415 chunks
#
... and it really didn't free anything.
On 02/25/2014 11:49 AM, Marcus Sundman wrote:
Hi
I get No space left on device and it is unclear why:
# df -h|grep sda3
/dev
up will eventually get to the point of moving at least one
chunk, which should be all that's needed at this point.
Hugo.
On 02/25/2014 11:49 AM, Marcus Sundman wrote:
Hi
I get No space left on device and it is unclear why:
# df -h|grep sda3
/dev/sda3 413G 368G 45G 90% /home
Hello. I am experiencing No space left on device with a btrfs file
system, yet I cannot seem to find any exhausted resource. Could some
resource I do not know about be exhausted, or is this caused by
something else. Below is a trace of information that might be usefull,
please let me know
On Wed, Feb 12, 2014 at 10:51:12AM +0100, Jakob Truelsen wrote:
Hello. I am experiencing No space left on device with a btrfs file
system, yet I cannot seem to find any exhausted resource. Could some
resource I do not know about be exhausted, or is this caused by
something else. Below
On 12/02/2014 09:51, Jakob Truelsen wrote:
Hello. I am experiencing No space left on device with a btrfs file
system, yet I cannot seem to find any exhausted resource. Could some
resource I do not know about be exhausted, or is this caused by
something else. Below is a trace of information
~]$ mount
...
/dev/sda on /data type btrfs (rw,relatime,nospace_cache,enospc_debug)
[jakobt@soda ~]$ sudo btrfs balance start -dusage=0 /data
ERROR: error during balancing '/data' - No space left on device
There may be more info in syslog - try dmesg | tail
[jakobt@soda ~]$ touch /data/jakobt
,relatime,nospace_cache,enospc_debug)
[jakobt@soda ~]$ sudo btrfs balance start -dusage=0 /data
ERROR: error during balancing '/data' - No space left on device
There may be more info in syslog - try dmesg | tail
[jakobt@soda ~]$ touch /data/jakobt/monkey
touch: cannot touch ‘/data/jakobt/monkey
On Wed, 15 Jan 2014 21:22:08 +0100
Tomasz Chmielewski man...@wpkg.org wrote:
What kernel version? Can you:
umount
dmesg -n7
mount
And then try to reproduce the behavior and note any kernel messages
in dmesg?
Turns out it's reproducible, with 3.13-rc8.
After reboot, I've
However:
# dd if=/dev/urandom of=bigfile
dd: writing to `bigfile': No space left on device
186+0 records in
185+0 records out
94720 bytes (95 kB) copied, 0.0144045 s, 6.6 MB/s
I don't understand why - can anyone explain?
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list
. 1.25+ GiB free. Metadata
chunks are a quarter GiB (256 MiB) each, so that's several chunks worth,
free.
However:
# dd if=/dev/urandom of=bigfile
dd: writing to `bigfile': No space left on device
186+0 records in
185+0 records out
94720 bytes (95 kB) copied, 0.0144045 s, 6.6 MB/s
I
, RAID1: total=32.00MiB, used=268.00KiB
Metadata, RAID1: total=53.00GiB, used=51.71GiB
However:
# dd if=/dev/urandom of=bigfile
dd: writing to `bigfile': No space left on device
186+0 records in
185+0 records out
94720 bytes (95 kB) copied, 0.0144045 s, 6.6 MB/s
I don't understand
Am Mittwoch, 15. Januar 2014, 19:05:41 schrieb Duncan:
But just as my already allocated mixed-mode chunks were just about full
and I needed another one allocated to complete the job, so your data
chunks are full or very close, according to btrfs fi df, and you need a
new one allocated (and
# dd if=/dev/urandom of=bigfile
dd: writing to `bigfile': No space left on device
186+0 records in
185+0 records out
94720 bytes (95 kB) copied, 0.0144045 s, 6.6 MB/s
I don't understand why - can anyone explain?
What kernel version? Can you:
umount
dmesg -n7
mount
Martin Steigerwald posted on Wed, 15 Jan 2014 20:40:29 +0100 as excerpted:
Am Mittwoch, 15. Januar 2014, 19:05:41 schrieb Duncan:
But just as my already allocated mixed-mode chunks were just about full
and I needed another one allocated to complete the job, so your data
chunks are full or
not sure if it is
related.
The obvious symptoms are that services on my system started crashing
with no space left on device errors.
└» mount |grep /mnt/ssd
/dev/sda2 on /mnt/ssd type btrfs
(rw,noatime,compress=lzo,ssd,noacl,space_cache)
└» btrfs fi df /mnt/ssd
Data, single: total=113.11GiB
Thomas Kuther posted on Mon, 13 Jan 2014 11:29:38 +0100 as excerpted:
This shows only half the story, tho. You also need the output of btrfs
fi show /mnt/ssd. Btrfs fi show displays how much of the total
available space is chunk-allocated; btrfs fi df displays how much of
the chunk-
left on device errors.
└» mount |grep /mnt/ssd
/dev/sda2 on /mnt/ssd type btrfs
(rw,noatime,compress=lzo,ssd,noacl,space_cache)
└» btrfs fi df /mnt/ssd
Data, single: total=113.11GiB, used=90.02GiB
System, DUP: total=64.00MiB, used=24.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP
I did some more digging, and I think I have two maybe unrelated issues here.
The no space left on device could be caused by the amount of metadata
used. I defragmented the KVM image and other parts, ran a balance start
-dusage=5, and now it looks like
└» btrfs fi df /
Data, single: total
201 - 300 of 421 matches
Mail list logo