Hello everyone,
I've ran into problems with _very_ slow unmounting of my btrfs-formatted
backup volume. I have a suspicion what might be the cause but maybe
someone with more experience with the btrfs code could enlighten me
whether it is actually correct.
The situation is the following: I
On 04/16/2013 10:10 AM, Sander wrote:
Liu Bo wrote (ao):
On Tue, Apr 16, 2013 at 02:28:51AM +0200, Ochi wrote:
The situation is the following: I have created a backup-volume to
which I regularly rsync a backup of my system into a subvolume.
After rsync'ing, I take a _read-only_ snapshot
Hi,
just wanted to say that I'm having the very same issue with kernel
3.18.4, btrfs-progs 3.18.1 (with or without -e option) - even with
completely fresh and/or empty snapshots. I'm just starting to experiment
with send/receive, so I don't know whether I have a fundamentally wrong
idea what
When I upgrade to the 3.19.2 Kernel I get a deadlocked boot:
INFO: task mount:302 blocked for more than 120 seconds.
INFO: task btrfs-transacti:329 blocked for more than 120 seconds.
I had a similar behavior today after I accidentally pulled the power
plug of my machine (Arch Linux, Kernel
Hi,
it seems like I triggered a bug after deleting some (actually all)
subvolumes from a 2 TB backup volume (about 1.5 TB worth of data, around
20 subvolumes, btrfs-cleaner took quite a long time), and running a
btrfs filesystem defrag . within the volume afterwards, after cleaner
seemed to
Hello,
here is the journal.log (I hope). It's quite interesting. I rebooted the
machine, performed a mkfs.btrfs on dm-{2,3,4} and dm-3 was missing
afterwards (around timestamp 66.*). However, I then logged into the
machine from another terminal (around timestamp 118.*) which triggered
I should have added some more technical info. Here you go:
Arch Linux with systemd 233
Kernel linux-lts 4.9.27
btrfs-progs 4.10.2
Example session:
root@nas> ls /dev/dm-*
/dev/dm-0 /dev/dm-1 /dev/dm-2 /dev/dm-3 /dev/dm-4
root@nas> ls -l /dev/mapper
total 0
lrwxrwxrwx 1 root root 7 May
Hello,
okay, I think I now have a repro that is stupidly simple, I'm not even
sure if I overlook something here. No multi-device btrfs involved, but
notably it does happen with btrfs, but not with e.g. ext4.
[Sidenote: At first I thought it had to do with systemd-cryptsetup
opening multiple
Hello,
while trying to initialize a btrfs RAID1 on my new NAS using LUKS
crypt-devices for each of the btrfs RAID devices, I have seen "random"
weirdness shortly after mkfs.
It seems to boil down to the problem that after mkfs.btrfs, some of the
/dev/dm-* nodes (as well as the corresponding
On 12.05.2017 13:25, Austin S. Hemmelgarn wrote:
On 2017-05-11 19:24, Ochi wrote:
Hello,
here is the journal.log (I hope). It's quite interesting. I rebooted the
machine, performed a mkfs.btrfs on dm-{2,3,4} and dm-3 was missing
afterwards (around timestamp 66.*). However, I then logged
Hello,
looking at the journals of three different machines running btrfs on
crypt-devices on SSDs for root (dm-0 in the logs below) and other
volumes, I'm seeing space cache warnings recurring for the same blocks
over and over again. The machines are usually (re)booted once a day. See
below
11 matches
Mail list logo
