the
robustness or uptime benefits that are expected of RAID-10.
In order to remove this potentially catestrophic confusion, BTRFS should
either call their RAID-10 implementation something else, or they should
adhere to the long-established definition of RAID-10.
Peter Ashford
--
To unsubscribe
of the above is more reliable, or
which I would prefer.
I believe that someone who understands the code in depth (and that may
also be one of the people above) determine exactly how BTRFS implements
RAID-10.
Thank you.
Peter Ashford
--
To unsubscribe from this list: send the line unsubscribe linux
rather quickly (only a year or
two).
I expect that the difficult part will be to optimize the performance of
BTRFS. Hopefully those tests (and others, yet to be developed) will be
able to keep it stable while the code is optimized for performance.
Peter Ashford
--
To unsubscribe from this list
is the free space that you expected: 300GB or 600GB and why
?
You should see 300GB free. That's what you'll see with RAID-1 with a
hardware RAID controller, and with MD RAID. Why would you expect to see
anything else with BTRFS RAID?
Peter Ashford
Yeah, you pointed out the real problem here
for most (all?)
file-systems. As they fill, they get less efficient. The impact is
minimal for a while, then the curve hits a knee and performance drops.
Some file-systems have a setting to only allow the ROOT user to exceed a
specified percentage of file-system use.
Peter Ashford
--
To unsubscribe
in /data/2.
Peter Ashford
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
anything else.
Peter Ashford
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
experiences with other file-systems, including ZFS, show
that the most common solution is to just deliver to the user the actual
amount of unused disk space. Anything else changes this known value into
a guess or prediction.
Peter Ashford
--
To unsubscribe from this list: send the line unsubscribe linux
to see
anything else with BTRFS RAID?
Peter Ashford
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
In other words, BTRFS acts like any other filesystem with compression.
This is reasonable.
Peter Ashford
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
to be verified to be
thread-safe. If BTRFS is using the same compression/decompression
routines that other file-systems use, then the core code is almost
certainly thread-safe. Any BTRFS wrapper code will have to be verified.
Peter Ashford
--
To unsubscribe from this list: send the line
luck.
Peter Ashford
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
the reconstruct speed for this array, but that's not a
trivial task.
The 5MB/S that TM is seeing is fine, considering the small files he says
he has.
Peter Ashford
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More
The NetApp research shows that the incidence of silent corruption is a
lot greater than you would expect. RAID-6 doesn't save you from this.
You need BTRFS or ZFS RAID-6.
I was referring to hard read errors, not silent data corruption.
Peter Ashford
--
To unsubscribe from this list: send the line
will probably take a few years.
As with the IBM offer, the Oracle offer isn't done, and could fail. At this
point, Chris is correct in choosing to move forward with BTRFS. As for what
happens when/if Oracle buys Sun, that's best decided AFTER it happens.
Peter Ashford
--
To unsubscribe from
It was possible to enter sector sizes larger than a memory page. This would
result in some unpleasantness, including hangs and crashes. This patch also
adds a minimum sector size of 512 bytes.
# diff -u mkfs.c- mkfs.c
--- mkfs.c- 2009-01-22 13:39:21.0 -0800
+++ mkfs.c
Yet another patch for mkfs input data verification.
# diff -u mkfs.c- mkfs.c
--- mkfs.c- 2009-01-23 19:26:33.0 -0800
+++ mkfs.c 2009-01-23 19:33:07.0 -0800
@@ -406,13 +406,23 @@
exit(1);
}
- if (leafsize sectorsize || (leafsize (sectorsize
In mkfs.btrfs, the sector size must be a power of two for the second half of
the leafsize and nodesize checks to work, but sectorsize is never validated.
# diff -u mkfs.c- mkfs.c
--- mkfs.c- 2009-01-20 11:37:39.0 -0800
+++ mkfs.c 2009-01-22 10:13:49.0 -0800
@@ -391,14
?
Thank you.
Peter Ashford
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
19 matches
Mail list logo
