From: Thomas Kuther <tom@kuther.net>
To: linux-btrfs@vger.kernel.org
Subject: Issues with "no space left on device" maybe related to 3.13 and/or kvm disk image fragmentation
Date: Sun, 12 Jan 2014 21:24:31 +0100 [thread overview]
Message-ID: <52D2F9FF.5060905@kuther.net> (raw)
Hello,
I'm experiencing an interesting issue with the BTRFS filesystem on my
SSD drive. It first occured some time after the upgrade to kernel
3.13-rc (-rc3 was my first 3.13-rc) but I'm 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, used=90.02GiB
System, DUP: total=64.00MiB, used=24.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=3.00GiB, used=2.46GiB
I use snapper on two subvolumes of that BTRFS volume (/ and /home) -
each keeping 7 daily snapshots and up to 10 hourlys.
When I saw those errors I started to delete most of the older snapshots,
and the issue went away instantly, but this couldn't be a solution nor a
workaround.
I do though have a "usual suspect" on that BTRFS volume. A KVM disk
image of a Win8 VM (I _need_ Adobe Lightroom)
» lsattr /mnt/ssd/kvm-images/
---------------C /mnt/ssd/kvm-images/Windows_8_Pro.qcow2
So the image has CoW disabled. Now comes the interesting part:
I'm trying to copy off the image to my raid5 array (BTRFS ontop of a
mdraid 5 - absolutely no issues with that one), but the cp process seems
like it's stalled.
After one hour the size of the destination copy is still 0 bytes. iotop
almost constantly show values like
TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
4636 be/4 tom 14.40 K/s 0.00 B/s 0.00 % 0.71 % cp
/mnt/ssd/kvm-images/Windows_8_Pro.qcow2 .
It tries to read the file with some 14K/s and writes absolutely nothing.
Any idea what's going wrong here, or suggestions how to get that qcow
file copied off? I do have a backup, but honestly that one is quite aged
- so simply rm'ing it would be the very last thing I'd like to try.
Regards,
Tom
PS: please reply-to-all, I'm not subscribed. Thanks.
next reply other threads:[~2014-01-12 20:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-12 20:24 Thomas Kuther [this message]
2014-01-12 23:05 ` Issues with "no space left on device" maybe related to 3.13 and/or kvm disk image fragmentation Thomas Kuther
2014-01-13 7:21 ` 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=52D2F9FF.5060905@kuther.net \
--to=tom@kuther.net \
--cc=linux-btrfs@vger.kernel.org \
/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