On Tue, Aug 01, 2017 at 01:39:59PM -0400, 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.liu@xxxxxxxxxx> 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. > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
