Dear btrfs-developers,
thank you for making such a nice and innovative filesystem. I do have a
small complaint however :-)
I read the documentation and liked the idea of having a multiple-device
filesystem with mirrored metadata while having data in single mode.
This would be perfect for my
On Tue, 24 Jun 2014 12:42:00 +0200
Gerald Hopf gerald.h...@nv-systems.net wrote:
The -d single allocator is useless (or broken?).
It's just not designed with your use case in mind. It operates on the level of
allocation extents (if I'm not mistaken), not of whole files.
If you want to join
Gerald Hopf posted on Tue, 24 Jun 2014 12:42:00 +0200 as excerpted:
After copying, I then unmounted the filesystem, switched off one of the
two 3TB USB disks and mounted the remaining 3TB disk in recovery mode
(-o degraded,ro) and proceeded to check whether any data was still left
alive.
On 24.06.2014 13:02, Roman Mamedov wrote:
If you want to join multiple devices with a per-file granularity (so
that a single file is wholely stored on one given device), check out
the FUSE filesystem called mhddfs; I wrote an article about it some
time ago: https://romanrm.net/mhddfs
Thank
On 24.06.2014 13:45, Duncan wrote:
- not a single one (!) of the big files (3GB-15GB) survived
A little familiarity with btrfs' chunk allocator and it's obvious what
happened. The critical point is that btrfs data chunks are 1 GiB in
size, so files over a GiB will require multiple data
I somehow have doubts that a complex filesystem is the right project for
me to start learning C, so I'll have to pass :-) No huge corporation
with that itch behind me either, and I guess it will be more than a few
hours for a btrfs programmer so no way I could sponsor that on my own.
Whether
