Hello,
>
> Hello,
>
>>
>> Could you check how many extents with BTRFS and Ext4:
>> # filefrag test1
>
> So my findings are odd:
>
> On BTRFS when I run fio with a single worker thread (target file is
> 12GB large,and its 100% random write of 4kb blocks), then number of
> extents reported by f
Processes keep getting stuck in btrfs_evict_inode during unlink.
I've seen this dozens of times, usually when two subvols on a btrfs
filesystem are active at the same time (i.e. it never happens on
single-subvol filesystems). It happens on kernel versions v3.15..v3.18.3.
This used to happen with
glibc 2.10+ (5+ years old) enables all the desired features:
_XOPEN_SOURCE 700, __XOPEN2K8, POSIX_C_SOURCE, DEFAULT_SOURCE; with a
single _GNU_SOURCE define in the makefile alone. For portability to
other libc implementations (e.g. dietlibc) _XOPEN_SOURCE=700 is also
defined.
This also resolves De
renaming read-only subvolumes works fine, as long as you dont move them
to a new directory.
create a ro snapshot, and mv it to a subdir or a parent directory. it
fails with 'Read-only file system'. no nested-subvolumes involved, just
the base and the single snapshot.
is this a bug? is this by de
On Sat, Jan 17, 2015 at 01:03:20PM +0100, G EO wrote:
> I know I have discussed it already on this list, but unfortunately it
> did no work out for me.
> I am creating backups with btrfs send/receive, like described on the
> wiki page https://btrfs.wiki.kernel.org/index.php/Incremental_Backup.
>
>
I know I have discussed it already on this list, but unfortunately it
did no work out for me.
I am creating backups with btrfs send/receive, like described on the
wiki page https://btrfs.wiki.kernel.org/index.php/Incremental_Backup.
That means I have a subvolume "home", create a snapshot
"home-sna
