I think in principle: No.
It is something that should be documented as advise in the VM software
documentation. But things like storage management is the domain of the
distribution or systems administrator.
There might be a situation where the VM software can directly use a
btrfs filesystem
On 15/02/12 17:59, Hugo Mills wrote:
It's a temporary location (6 months and counting) while
kernel.org is static-pages-only.
Hugo.
Couldn't btrfs.wiki.kernel.org be made a CNAME for btrfs.ipv5.de for the
time being until kernel.org is up and running?
Or alternatively all requests
On 25/07/11 23:10, Mark Fasheh wrote:
On Fri, Jul 22, 2011 at 09:45:19AM +0900, Tsutomu Itoh wrote:
(2011/07/22 4:48), Mark Fasheh wrote:
In addition to properly handling allocation failure from btrfs_alloc_path, I
also fixed up the kzalloc error handling code immediately below it.
On 02/03/11 10:05, Thomas Bellman wrote:
Will the stripe *width* be configurable? If I have something like a
Sun Thor with 48 drives, I would probably not be entirely comfortable
having 46 drives data and 2 drives parity; too little redundancy for
my tastes. 2 drives parity per 10 drives
On 18/11/10 15:31, Bart Noordervliet wrote:
On Wed, Nov 17, 2010 at 19:07, Gordan Bobic gor...@bobich.net wrote:
Since BTRFS is already doing some relatively radical things, I would like to
suggest that RAID5 and RAID6 be deemed obsolete. RAID5 isn't safely usable
for arrays bigger than about
Hello,
Pherhaps it would be a good idea to add a tracepoint before each return
ENOSPC? It shouldn't matter too much since a reasonable assumption would
be that filesystems aren't running out of space most of the time. And
you can use 'perf' for more insight in these cases without recompiling
the
