On Wed, Nov 18, 2009 at 09:59:24AM -0800, Roland Dreier wrote:
Yeah df is just a fun ball of wax in many respects. We don't take into
account
RAID and we don't subtrace space thats strictly for metadata, so there
are
several things that need to be fixed for df. Thanks,
But
- Unless I'm missing something, there doesn't seem to be any way later
on to see that I set the data policy to raid1, except using
btrfs-dump-tree and checking the flags bits for the appropriate
group. Which can make things confusing if I have a bunch of btrfs
Yeah df is just a fun ball of wax in many respects. We don't take into
account
RAID and we don't subtrace space thats strictly for metadata, so there are
several things that need to be fixed for df. Thanks,
But as we have said many times... if we have different
raid types
Andrey Kuzmin wrote:
On Tue, Nov 17, 2009 at 12:48 AM, jim owens jow...@hp.com wrote:
But as we have said many times... if we have different
raid types active on different files, any attempt to make
Late question, but could you please explain it a bit further (or point
me to respective
On Tue, Nov 17, 2009 at 6:25 PM, jim owens jow...@hp.com wrote:
snip
So we know the raw free blocks, but can not guarantee
how many raw blocks per new user write-block will be
consumed because we do not know what topology will be
in effect for a new write.
We could cheat and use worst-case
I've just started playing around with btrfs RAID1, and I've noticed a
couple of what seem to be UI issues. Suppose I do something like
mkfs.btrfs -d raid1 -m raid1 dev1 dev2. I see the following minor
usability problems:
- Unless I'm missing something, there doesn't seem to be any way later
