Russell Coker posted on Fri, 23 May 2014 13:54:46 +1000 as excerpted:
Is anyone doing research on how much free disk space is required on
BTRFS for good performance? If a rumor (whether correct or incorrect)
goes around that you need 20% free space on a BTRFS filesystem for
performance then
On 2014-05-21 19:05, Martin wrote:
Very good comment from Ashford.
Sorry, but I see no advantages from Russell's replies other than for a
feel-good factor or a dangerous false sense of security. At best,
there is a weak justification that for metadata, again going from 2% to
4% isn't
I thought an important idea behind btrfs was that we avoid by design
in the first place the very long and vulnerable RAID rebuild scenarios
suffered for block-level RAID...
This may be true for SSD disks - for ordinary disks it's not entirely
the case.
For most RAID rebuilds, it still seems
anyone
have a worst-case scenario for testing?
The ZFS design involves ditto blocks being spaced apart due to the fact
that corruption tends to have some spacial locality. So you are adding
an extra seek.
The worst case would be when you have lots of small synchronous writes,
probably
20% free space on a BTRFS filesystem for performance then that
will vastly outweigh the space used for metadata.
The ZFS design involves ditto blocks being spaced apart due to the fact
that corruption tends to have some spacial locality. So you are adding
an extra seek.
The worst case
Very good comment from Ashford.
Sorry, but I see no advantages from Russell's replies other than for a
feel-good factor or a dangerous false sense of security. At best,
there is a weak justification that for metadata, again going from 2% to
4% isn't going to be a great problem (storage is cheap
On 20/5/2014 5:07 πμ, Russell Coker wrote:
On Mon, 19 May 2014 23:47:37 Brendan Hide wrote:
This is extremely difficult to measure objectively. Subjectively ... see
below.
[snip]
*What other failure modes* should we guard against?
I know I'd sleep a /little/ better at night knowing that a
On 2014-05-19 22:07, Russell Coker wrote:
On Mon, 19 May 2014 23:47:37 Brendan Hide wrote:
This is extremely difficult to measure objectively. Subjectively ... see
below.
[snip]
*What other failure modes* should we guard against?
I know I'd sleep a /little/ better at night knowing that a
On 2014/05/20 04:07 PM, Austin S Hemmelgarn wrote:
On 2014-05-19 22:07, Russell Coker wrote:
[snip]
As an aside, I'd really like to be able to set RAID levels by subtree. I'd
like to use RAID-1 with ditto blocks for my important data and RAID-0 for
unimportant data.
But the proposed changes
and unavoidable result of having more copies of the metadata.
The actual impact of this would depend on the file-system usage pattern,
but would probably be unnoticeable in most circumstances. Does anyone
have a worst-case scenario for testing?
The ZFS design involves ditto blocks being spaced apart due
On 18/05/14 17:09, Russell Coker wrote:
On Sat, 17 May 2014 13:50:52 Martin wrote:
[...]
Do you see or measure any real advantage?
Imagine that you have a RAID-1 array where both disks get ~14,000 read
errors.
This could happen due to a design defect common to drives of a particular
On 2014/05/19 10:36 PM, Martin wrote:
On 18/05/14 17:09, Russell Coker wrote:
On Sat, 17 May 2014 13:50:52 Martin wrote:
[...]
Do you see or measure any real advantage?
[snip]
This is extremely difficult to measure objectively. Subjectively ... see
below.
[snip]
*What other failure modes*
On Mon, 19 May 2014 23:47:37 Brendan Hide wrote:
This is extremely difficult to measure objectively. Subjectively ... see
below.
[snip]
*What other failure modes* should we guard against?
I know I'd sleep a /little/ better at night knowing that a double disk
failure on a raid5/1/10
On Sat, 17 May 2014 13:50:52 Martin wrote:
On 16/05/14 04:07, Russell Coker wrote:
https://blogs.oracle.com/bill/entry/ditto_blocks_the_amazing_tape
Probably most of you already know about this, but for those of you who
haven't the above describes ZFS ditto blocks which is a good feature
On 16/05/14 04:07, Russell Coker wrote:
https://blogs.oracle.com/bill/entry/ditto_blocks_the_amazing_tape
Probably most of you already know about this, but for those of you who
haven't
the above describes ZFS ditto blocks which is a good feature we need on
BTRFS. The briefest summary
On Sat, May 17, 2014 at 01:50:52PM +0100, Martin wrote:
On 16/05/14 04:07, Russell Coker wrote:
https://blogs.oracle.com/bill/entry/ditto_blocks_the_amazing_tape
Probably most of you already know about this, but for those of you who
haven't
the above describes ZFS ditto blocks which
https://blogs.oracle.com/bill/entry/ditto_blocks_the_amazing_tape
Probably most of you already know about this, but for those of you who haven't
the above describes ZFS ditto blocks which is a good feature we need on
BTRFS. The briefest summary is that on top of the RAID redundancy
17 matches
Mail list logo
