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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.