On 08/01/2017 01:39 PM, Austin S. Hemmelgarn wrote:
On 2017-08-01 13:25, Roman Mamedov wrote:
On Tue, 1 Aug 2017 10:14:23 -0600
Liu Bo <bo.li....@oracle.com> wrote:
This aims to fix write hole issue on btrfs raid5/6 setup by adding a
separate disk as a journal (aka raid5/6 log), so that after unclean
shutdown we can make sure data and parity are consistent on the raid
array by replaying the journal.
Could it be possible to designate areas on the in-array devices to be
used as
journal?
While md doesn't have much spare room in its metadata for extraneous
things
like this, Btrfs could use almost as much as it wants to, adding to
size of the
FS metadata areas. Reliability-wise, the log could be stored as RAID1
chunks.
It doesn't seem convenient to need having an additional storage device
around
just for the log, and also needing to maintain its fault tolerance
yourself (so
the log device would better be on a mirror, such as mdadm RAID1? more
expense
and maintenance complexity).
I agree, MD pretty much needs a separate device simply because they
can't allocate arbitrary space on the other array members. BTRFS can do
that though, and I would actually think that that would be _easier_ to
implement than having a separate device.
That said, I do think that it would need to be a separate chunk type,
because things could get really complicated if the metadata is itself
using a parity raid profile.
Thanks for running with this Liu, I'm reading through all the patches.
I do agree that it's better to put the logging into a dedicated chunk
type, that way we can have it default to either double or triple mirroring.
-chris
--
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
