On 08/02/2017 08:47 PM, Chris Mason wrote:
>> 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
On 08/23/2017 05:28 PM, Chris Murphy wrote:
> - dynamically sized stripes, so that writes can always be full stripe
> writes, no overwrites, and atomic
Think about also that a block could be deallocated (i.e. canceling a file of
4kb). This leads to have some holes that you cannot fill without a
On 2017-08-23 11:28, Chris Murphy wrote:
On Wed, Aug 2, 2017 at 2:27 PM, Liu Bo wrote:
On Wed, Aug 02, 2017 at 10:41:30PM +0200, Goffredo Baroncelli wrote:
What I want to understand, is if it is possible to log only the "partial
stripe" RMW cycle.
I think your
On Wed, Aug 2, 2017 at 2:27 PM, Liu Bo wrote:
> On Wed, Aug 02, 2017 at 10:41:30PM +0200, Goffredo Baroncelli wrote:
>> What I want to understand, is if it is possible to log only the "partial
>> stripe" RMW cycle.
>>
>
> I think your point is valid if all data is written
On 2017-08-03 06:02, Duncan wrote:
> Liu Bo posted on Wed, 02 Aug 2017 14:27:21 -0600 as excerpted:
>
> It is correct reading this as: all data is written two times ?
>
> If as is being discussed the log is mirrored by default that'd be three
> times...
And for raid6 you need to do it 4
Liu Bo posted on Wed, 02 Aug 2017 14:27:21 -0600 as excerpted:
>> >> It is correct reading this as: all data is written two times ?
If as is being discussed the log is mirrored by default that'd be three
times...
Parity-raid is slow and of course normally has the infamous write hole
this
On Wed, Aug 02, 2017 at 10:41:30PM +0200, Goffredo Baroncelli wrote:
> Hi Liu,
>
> thanks for your reply, below my comments
> On 2017-08-02 19:57, Liu Bo wrote:
> > On Wed, Aug 02, 2017 at 12:14:27AM +0200, Goffredo Baroncelli wrote:
> >> On 2017-08-01 19:24, Liu Bo wrote:
> >>> On Tue, Aug 01,
Hi Liu,
thanks for your reply, below my comments
On 2017-08-02 19:57, Liu Bo wrote:
> On Wed, Aug 02, 2017 at 12:14:27AM +0200, Goffredo Baroncelli wrote:
>> On 2017-08-01 19:24, Liu Bo wrote:
>>> On Tue, Aug 01, 2017 at 07:42:14PM +0200, Goffredo Baroncelli wrote:
Hi Liu,
On
On Wed, Aug 02, 2017 at 12:14:27AM +0200, Goffredo Baroncelli wrote:
> On 2017-08-01 19:24, Liu Bo wrote:
> > On Tue, Aug 01, 2017 at 07:42:14PM +0200, Goffredo Baroncelli wrote:
> >> Hi Liu,
> >>
> >> On 2017-08-01 18:14, Liu Bo wrote:
> >>> This aims to fix write hole issue on btrfs raid5/6
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 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
On 2017-08-01 23:00, Christoph Anton Mitterer wrote:
> Hi.
>
> Stupid question:
> Would the write hole be closed already, if parity was checksummed?
No.
The write hole problem is due to a combination of two things:
a) misalignment between parity and data (i.e. unclean shutdown)
b) loosing of a
On 2017-08-01 19:24, Liu Bo wrote:
> On Tue, Aug 01, 2017 at 07:42:14PM +0200, Goffredo Baroncelli wrote:
>> Hi Liu,
>>
>> On 2017-08-01 18:14, Liu Bo 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
Hi.
Stupid question:
Would the write hole be closed already, if parity was checksummed?
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
On Tue, Aug 01, 2017 at 07:42:14PM +0200, Goffredo Baroncelli wrote:
> Hi Liu,
>
> On 2017-08-01 18:14, Liu Bo 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
On Tue, Aug 01, 2017 at 10:56:39AM -0600, Liu Bo wrote:
> On Tue, Aug 01, 2017 at 05:28:57PM +, Hugo Mills wrote:
> >Hi,
> >
> >Great to see something addressing the write hole at last.
> >
> > On Tue, Aug 01, 2017 at 10:14:23AM -0600, Liu Bo wrote:
> > > This aims to fix write hole
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 wrote:
> >
> > > This aims to fix write hole issue on btrfs raid5/6 setup by adding a
> > > separate disk as a
On Tue, Aug 01, 2017 at 10:25:47PM +0500, Roman Mamedov wrote:
> On Tue, 1 Aug 2017 10:14:23 -0600
> Liu Bo 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
> >
On Tue, Aug 01, 2017 at 05:28:57PM +, Hugo Mills wrote:
>Hi,
>
>Great to see something addressing the write hole at last.
>
> On Tue, Aug 01, 2017 at 10:14:23AM -0600, Liu Bo wrote:
> > This aims to fix write hole issue on btrfs raid5/6 setup by adding a
> > separate disk as a
Hi Liu,
On 2017-08-01 18:14, Liu Bo 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.
>
it
On 2017-08-01 13:25, Roman Mamedov wrote:
On Tue, 1 Aug 2017 10:14:23 -0600
Liu Bo 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
Hi,
Great to see something addressing the write hole at last.
On Tue, Aug 01, 2017 at 10:14:23AM -0600, Liu Bo 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
On Tue, 1 Aug 2017 10:14:23 -0600
Liu Bo 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
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.
The idea and the code are similar to the write-through mode
23 matches
Mail list logo