On Tue, Aug 01, 2017 at 01:39:59PM -0400, Austin S. Hemmelgarn wrote:

On 2017-08-01 13:25, Roman Mamedov wrote:

quoted

On Tue,  1 Aug 2017 10:14:23 -0600
Liu Bo [off-list ref] wrote:

quoted

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.

Yes and no, using chunks may need a new ioctl and diving into chunk
allocation/(auto)deletion maze.

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.

Exactly, esp. when balance comes into the picture.

Thanks,

-liubo