Re: Status of RAID5/6

On Wed, Apr 04, 2018 at 11:31:33PM +0200, Goffredo Baroncelli wrote: > On 04/04/2018 08:01 AM, Zygo Blaxell wrote: > > On Wed, Apr 04, 2018 at 07:15:54AM +0200, Goffredo Baroncelli wrote: > >> On 04/04/2018 12:57 AM, Zygo Blaxell wrote: > [...] > >> Before you pointed out that the non-contiguous

Re: Status of RAID5/6

On 04/04/2018 08:01 AM, Zygo Blaxell wrote: > On Wed, Apr 04, 2018 at 07:15:54AM +0200, Goffredo Baroncelli wrote: >> On 04/04/2018 12:57 AM, Zygo Blaxell wrote: [...] >> Before you pointed out that the non-contiguous block written has >> an impact on performance. I am replaying that the

Re: Status of RAID5/6

On Tue, Apr 03, 2018 at 09:08:01PM -0600, Chris Murphy wrote: > On Tue, Apr 3, 2018 at 11:03 AM, Goffredo Baroncelli > wrote: > > On 04/03/2018 02:31 AM, Zygo Blaxell wrote: > >> On Mon, Apr 02, 2018 at 06:23:34PM -0400, Zygo Blaxell wrote: > >>> On Mon, Apr 02, 2018 at

Re: Status of RAID5/6

On Wed, Apr 04, 2018 at 07:15:54AM +0200, Goffredo Baroncelli wrote: > On 04/04/2018 12:57 AM, Zygo Blaxell wrote: > >> I have to point out that in any case the extent is physically > >> interrupted at the disk-stripe size. Assuming disk-stripe=64KB, if > >> you want to write 128KB, the first half

Re: Status of RAID5/6

On 04/04/2018 12:57 AM, Zygo Blaxell wrote: >> I have to point out that in any case the extent is physically >> interrupted at the disk-stripe size. Assuming disk-stripe=64KB, if >> you want to write 128KB, the first half is written in the first disk, >> the other in the 2nd disk. If you want to

Re: Status of RAID5/6

On Tue, Apr 3, 2018 at 11:03 AM, Goffredo Baroncelli wrote: > On 04/03/2018 02:31 AM, Zygo Blaxell wrote: >> On Mon, Apr 02, 2018 at 06:23:34PM -0400, Zygo Blaxell wrote: >>> On Mon, Apr 02, 2018 at 11:49:42AM -0400, Austin S. Hemmelgarn wrote: On 2018-04-02 11:18,

Re: Status of RAID5/6

On Tue, Apr 03, 2018 at 07:03:06PM +0200, Goffredo Baroncelli wrote: > On 04/03/2018 02:31 AM, Zygo Blaxell wrote: > > On Mon, Apr 02, 2018 at 06:23:34PM -0400, Zygo Blaxell wrote: > >> On Mon, Apr 02, 2018 at 11:49:42AM -0400, Austin S. Hemmelgarn wrote: > >>> On 2018-04-02 11:18, Goffredo

Re: Status of RAID5/6

On 04/03/2018 02:31 AM, Zygo Blaxell wrote: > On Mon, Apr 02, 2018 at 06:23:34PM -0400, Zygo Blaxell wrote: >> On Mon, Apr 02, 2018 at 11:49:42AM -0400, Austin S. Hemmelgarn wrote: >>> On 2018-04-02 11:18, Goffredo Baroncelli wrote: I thought that a possible solution is to create BG with

Re: Status of RAID5/6

On Mon, Apr 02, 2018 at 06:23:34PM -0400, Zygo Blaxell wrote: > On Mon, Apr 02, 2018 at 11:49:42AM -0400, Austin S. Hemmelgarn wrote: > > On 2018-04-02 11:18, Goffredo Baroncelli wrote: > > > I thought that a possible solution is to create BG with different > > number of data disks. E.g. supposing

Re: Status of RAID5/6

On Mon, Apr 02, 2018 at 11:49:42AM -0400, Austin S. Hemmelgarn wrote: > On 2018-04-02 11:18, Goffredo Baroncelli wrote: > > On 04/02/2018 07:45 AM, Zygo Blaxell wrote: > > [...] > > > It is possible to combine writes from a single transaction into full > > > RMW stripes, but this *does* have an

Re: Status of RAID5/6

On 04/02/2018 07:45 AM, Zygo Blaxell wrote: [...] > It is possible to combine writes from a single transaction into full > RMW stripes, but this *does* have an impact on fragmentation in btrfs. > Any partially-filled stripe is effectively read-only and the space within > it is inaccessible until

Re: Status of RAID5/6

On Sun, Apr 01, 2018 at 03:11:04PM -0600, Chris Murphy wrote: > (I hate it when my palm rubs the trackpad and hits send prematurely...) > > > On Sun, Apr 1, 2018 at 2:51 PM, Chris Murphy wrote: > > >> Users can run scrub immediately after _every_ unclean shutdown to >

Re: Status of RAID5/6

(I hate it when my palm rubs the trackpad and hits send prematurely...) On Sun, Apr 1, 2018 at 2:51 PM, Chris Murphy wrote: >> Users can run scrub immediately after _every_ unclean shutdown to >> reduce the risk of inconsistent parity and unrecoverable data should >> a

Re: Status of RAID5/6

On Sat, Mar 31, 2018 at 9:45 PM, Zygo Blaxell wrote: > On Sat, Mar 31, 2018 at 04:34:58PM -0600, Chris Murphy wrote: >> Write hole happens on disk in Btrfs, but the ensuing corruption on >> rebuild is detected. Corrupt data never propagates. > > Data written with

Re: Status of RAID5/6

On Sat, Mar 31, 2018 at 04:34:58PM -0600, Chris Murphy wrote: > On Sat, Mar 31, 2018 at 12:57 AM, Goffredo Baroncelli > wrote: > > On 03/31/2018 07:03 AM, Zygo Blaxell wrote: > btrfs has no optimization like mdadm write-intent bitmaps; recovery > is always a

Re: Status of RAID5/6

On Sat, Mar 31, 2018 at 12:57 AM, Goffredo Baroncelli wrote: > On 03/31/2018 07:03 AM, Zygo Blaxell wrote: btrfs has no optimization like mdadm write-intent bitmaps; recovery is always a full-device operation. In theory btrfs could track modifications at the

Re: Status of RAID5/6

On Sat, Mar 31, 2018 at 11:36:50AM +0300, Andrei Borzenkov wrote: > 31.03.2018 11:16, Goffredo Baroncelli пишет: > > On 03/31/2018 09:43 AM, Zygo Blaxell wrote: > >>> The key is that if a data write is interrupted, all the transaction > >>> is interrupted and aborted. And due to the COW nature of

Re: Status of RAID5/6

On 03/31/2018 09:43 AM, Zygo Blaxell wrote: >> The key is that if a data write is interrupted, all the transaction >> is interrupted and aborted. And due to the COW nature of btrfs, the >> "old state" is restored at the next reboot. > This is not presently true with raid56 and btrfs. RAID56 on

Re: Status of RAID5/6

On Sat, Mar 31, 2018 at 08:57:18AM +0200, Goffredo Baroncelli wrote: > On 03/31/2018 07:03 AM, Zygo Blaxell wrote: > >>> btrfs has no optimization like mdadm write-intent bitmaps; recovery > >>> is always a full-device operation. In theory btrfs could track > >>> modifications at the chunk level

Re: Status of RAID5/6

On 03/31/2018 07:03 AM, Zygo Blaxell wrote: >>> btrfs has no optimization like mdadm write-intent bitmaps; recovery >>> is always a full-device operation. In theory btrfs could track >>> modifications at the chunk level but this isn't even specified in the >>> on-disk format, much less

Re: Status of RAID5/6

On Fri, Mar 30, 2018 at 06:14:52PM +0200, Goffredo Baroncelli wrote: > On 03/29/2018 11:50 PM, Zygo Blaxell wrote: > > On Wed, Mar 21, 2018 at 09:02:36PM +0100, Christoph Anton Mitterer wrote: > >> Hey. > >> > >> Some things would IMO be nice to get done/clarified (i.e. documented in > >> the Wiki

Re: Status of RAID5/6

On Fri, Mar 30, 2018 at 09:21:00AM +0200, Menion wrote: > Thanks for the detailed explanation. I think that a summary of this > should go in the btrfs raid56 wiki status page, because now it is > completely inconsistent and if a user comes there, ihe may get the > impression that the raid56 is

Re: Status of RAID5/6

On 03/29/2018 11:50 PM, Zygo Blaxell wrote: > On Wed, Mar 21, 2018 at 09:02:36PM +0100, Christoph Anton Mitterer wrote: >> Hey. >> >> Some things would IMO be nice to get done/clarified (i.e. documented in >> the Wiki and manpages) from users'/admin's POV: [...] > >> - changing raid lvls? > >

Re: Status of RAID5/6

Thanks for the detailed explanation. I think that a summary of this should go in the btrfs raid56 wiki status page, because now it is completely inconsistent and if a user comes there, ihe may get the impression that the raid56 is just broken Still I have the 1 bilion dollar question: from your

Re: Status of RAID5/6

On Wed, Mar 21, 2018 at 09:02:36PM +0100, Christoph Anton Mitterer wrote: > Hey. > > Some things would IMO be nice to get done/clarified (i.e. documented in > the Wiki and manpages) from users'/admin's POV: > > Some basic questions: I can answer some easy ones: > - compression+raid? There

Re: Status of RAID5/6

Liu Bo wrote: On Wed, Mar 21, 2018 at 9:50 AM, Menion <men...@gmail.com> wrote: Hi all I am trying to understand the status of RAID5/6 in BTRFS I know that there are some discussion ongoing on the RFC patch proposed by Liu bo But it seems that everything stopped last summary. Also it men

Re: Status of RAID5/6

On 2018-03-21 16:02, Christoph Anton Mitterer wrote: On the note of maintenance specifically: - Maintenance tools - How to get the status of the RAID? (Querying kernel logs is IMO rather a bad way for this) This includes: - Is the raid degraded or not? Check for the 'degraded'

Re: Status of RAID5/6

.li...@gmail.com>: > On Wed, Mar 21, 2018 at 9:50 AM, Menion <men...@gmail.com> wrote: >> Hi all >> I am trying to understand the status of RAID5/6 in BTRFS >> I know that there are some discussion ongoing on the RFC patch >> proposed by Liu bo >> But it see

Re: Status of RAID5/6

Hey. Some things would IMO be nice to get done/clarified (i.e. documented in the Wiki and manpages) from users'/admin's POV: Some basic questions: - Starting with which kernels (including stable kernel versions) does it contain the fixes for the bigger issues from some time ago? - Exactly what

Re: Status of RAID5/6

On Wed, Mar 21, 2018 at 9:50 AM, Menion <men...@gmail.com> wrote: > Hi all > I am trying to understand the status of RAID5/6 in BTRFS > I know that there are some discussion ongoing on the RFC patch > proposed by Liu bo > But it seems that everything stopped last summary. Also

Status of RAID5/6

Hi all I am trying to understand the status of RAID5/6 in BTRFS I know that there are some discussion ongoing on the RFC patch proposed by Liu bo But it seems that everything stopped last summary. Also it mentioned about a "separate disk for journal", does it mean that the final impl

Status of raid5/6 in 2014?

Back in Feb 2013 there was quite a bit of press about the preliminary raid5/6 implementation in Btrfs. At the time it wasn't useful for anything other then testing and it's my understanding that this is still the case. I've seen a few git commits and some chatter on this list but it would appear

Re: Status of raid5/6 in 2014?

I personally consider proper RAID6 support with gracious non-intrusive handling of failing drives and a proper warning mechanism the most important missing feature of btrfs, and I know this view is shared by many others with software RAID based storage systems, currently limited by the existing