* On mdadm 3.2 and bad-block-log @ 2012-06-12 16:51 Asdo 2012-07-11 9:40 ` Alexander Lyakas 0 siblings, 1 reply; 10+ messages in thread From: Asdo @ 2012-06-12 16:51 UTC (permalink / raw) To: linux-raid Hello is it possible to keep mdadm 3.2 installed in the system (e.g. 3.2 as the monitoring daemon) and have an array with bad-block functionality (created with 3.3) running, or this will do a mess? Bad-block functionality is in mdadm-3.3 but this has not been released yet. I was thinking about using it only once to create the array. However I am still missing the manual for mdadm-3.3, where is that? without that I don't know how I should launch it to create an array with bad blocks. Another question: are older kernels such as 3.0 capable to run an array created with bad-block-log, obviously without using the bad-block-log functionality? oh but that could be dangerous, couldn't it... Thank you A. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: On mdadm 3.2 and bad-block-log 2012-06-12 16:51 On mdadm 3.2 and bad-block-log Asdo @ 2012-07-11 9:40 ` Alexander Lyakas 2012-07-16 3:41 ` NeilBrown 0 siblings, 1 reply; 10+ messages in thread From: Alexander Lyakas @ 2012-07-11 9:40 UTC (permalink / raw) To: NeilBrown; +Cc: linux-raid, Asdo Hi Neil, can you pls clarify whether the bad block management code in existing kernels is still considered experimental, and that's the reason there is no mdadm 3.3.x release yet? If yes, which kernel do you recommend to experiment with this feature? If no, should we then use the "devel-3.3" branch of mdadm, which was last updated ~1 year ago? Thanks, Alex. On Tue, Jun 12, 2012 at 7:51 PM, Asdo <asdo@shiftmail.org> wrote: > Hello > is it possible to keep mdadm 3.2 installed in the system (e.g. 3.2 as the > monitoring daemon) and have an array with bad-block functionality (created > with 3.3) running, or this will do a mess? > > Bad-block functionality is in mdadm-3.3 but this has not been released yet. > I was thinking about using it only once to create the array. > > However I am still missing the manual for mdadm-3.3, where is that? without > that I don't know how I should launch it to create an array with bad blocks. > > Another question: are older kernels such as 3.0 capable to run an array > created with bad-block-log, obviously without using the bad-block-log > functionality? oh but that could be dangerous, couldn't it... > > Thank you > A. > -- > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: On mdadm 3.2 and bad-block-log 2012-07-11 9:40 ` Alexander Lyakas @ 2012-07-16 3:41 ` NeilBrown 2012-07-16 7:41 ` Asdo 0 siblings, 1 reply; 10+ messages in thread From: NeilBrown @ 2012-07-16 3:41 UTC (permalink / raw) To: Alexander Lyakas; +Cc: linux-raid, Asdo [-- Attachment #1: Type: text/plain, Size: 2299 bytes --] On Wed, 11 Jul 2012 12:40:57 +0300 Alexander Lyakas <alex.bolshoy@gmail.com> wrote: > Hi Neil, > can you pls clarify whether the bad block management code in existing > kernels is still considered experimental, and that's the reason there > is no mdadm 3.3.x release yet? Given that you are finding bugs in it - yes, it is still experimental :-) The reason there is no 3.3.x release yet is that the amount of stuff that I want to include in 3.3 has grown substantially and as the bad block code is clearly still buggy, I probably don't want to rush it out :-) I'm hoping for August or September for 3.3. Probably September. > If yes, which kernel do you recommend to experiment with this feature? Always the latest. > If no, should we then use the "devel-3.3" branch of mdadm, which was > last updated ~1 year ago? Yes. I'll be pulling that code into 'master' once I've finished some code-cleanup that I want to do first. Thanks, NeilBrown > > Thanks, > Alex. > > > > On Tue, Jun 12, 2012 at 7:51 PM, Asdo <asdo@shiftmail.org> wrote: > > Hello > > is it possible to keep mdadm 3.2 installed in the system (e.g. 3.2 as the > > monitoring daemon) and have an array with bad-block functionality (created > > with 3.3) running, or this will do a mess? > > > > Bad-block functionality is in mdadm-3.3 but this has not been released yet. > > I was thinking about using it only once to create the array. > > > > However I am still missing the manual for mdadm-3.3, where is that? without > > that I don't know how I should launch it to create an array with bad blocks. > > > > Another question: are older kernels such as 3.0 capable to run an array > > created with bad-block-log, obviously without using the bad-block-log > > functionality? oh but that could be dangerous, couldn't it... > > > > Thank you > > A. > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 828 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: On mdadm 3.2 and bad-block-log 2012-07-16 3:41 ` NeilBrown @ 2012-07-16 7:41 ` Asdo 2012-07-16 7:55 ` Alexander Lyakas 0 siblings, 1 reply; 10+ messages in thread From: Asdo @ 2012-07-16 7:41 UTC (permalink / raw) To: NeilBrown; +Cc: Alexander Lyakas, linux-raid On 07/16/12 05:41, NeilBrown wrote: > and as the bad block code is > clearly still buggy, I probably don't want to rush it out :-) The bad block code is buggy... the one in the kernel or the one in mdadm-3.3 ? 'cause I am currently using an array created with bad block log on kernel 3.4.3... Thanks ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: On mdadm 3.2 and bad-block-log 2012-07-16 7:41 ` Asdo @ 2012-07-16 7:55 ` Alexander Lyakas 2012-07-16 8:56 ` Asdo 0 siblings, 1 reply; 10+ messages in thread From: Alexander Lyakas @ 2012-07-16 7:55 UTC (permalink / raw) To: Asdo; +Cc: linux-raid The mdadm code only reserves some space for bad-blocks log and notifies the kernel that this feature is enabled during array creation. On Mon, Jul 16, 2012 at 10:41 AM, Asdo <asdo@shiftmail.org> wrote: > On 07/16/12 05:41, NeilBrown wrote: >> >> and as the bad block code is >> clearly still buggy, I probably don't want to rush it out :-) > > > The bad block code is buggy... the one in the kernel or the one in mdadm-3.3 > ? > 'cause I am currently using an array created with bad block log on kernel > 3.4.3... > > Thanks ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: On mdadm 3.2 and bad-block-log 2012-07-16 7:55 ` Alexander Lyakas @ 2012-07-16 8:56 ` Asdo 2012-07-16 9:08 ` Alexander Lyakas 2012-07-17 1:49 ` NeilBrown 0 siblings, 2 replies; 10+ messages in thread From: Asdo @ 2012-07-16 8:56 UTC (permalink / raw) To: Alexander Lyakas; +Cc: linux-raid, Neil Brown Right, that's the reason of my question. Neil wrote "I probably don't want to rush it out" so that would mean that the buggy code is not "out" yet. So that would point to mdadm-3.3 because the bad block code of the kernel is already "out". However as you say the bad block code in mdadm-3.3 is very simple so it's strange that it could be buggy. Now thinking at myself: if there were bugs in the mdadm-3.3 I probably have dodged them because I was able to create the array. However if there are known bugs in the kernel code our data is still at risk so i'd rather ask. FWIW I am not using mdadm-3.3 as monitoring daemon: the daemon is mdadm-3.2 , I don't know if this "helps". Thank you A. On 07/16/12 09:55, Alexander Lyakas wrote: > The mdadm code only reserves some space for bad-blocks log and > notifies the kernel that this feature is enabled during array > creation. > > On Mon, Jul 16, 2012 at 10:41 AM, Asdo<asdo@shiftmail.org> wrote: >> On 07/16/12 05:41, NeilBrown wrote: >>> and as the bad block code is >>> clearly still buggy, I probably don't want to rush it out :-) >> >> The bad block code is buggy... the one in the kernel or the one in mdadm-3.3 >> ? >> 'cause I am currently using an array created with bad block log on kernel >> 3.4.3... >> >> Thanks ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: On mdadm 3.2 and bad-block-log 2012-07-16 8:56 ` Asdo @ 2012-07-16 9:08 ` Alexander Lyakas 2012-07-17 1:49 ` NeilBrown 1 sibling, 0 replies; 10+ messages in thread From: Alexander Lyakas @ 2012-07-16 9:08 UTC (permalink / raw) To: Asdo; +Cc: linux-raid, Neil Brown That's not what I was saying. The mdadm code to support bad blocks is really one or two lines. The rest is in the kernel. (On the other hand, the mdadm version which has those one or two lines is about a year behind the mainline mdadm, so it lacks many other things/fixes/improvements, but that's a different issue). Yes, the kernel code is out, but as Neil pointed out, it might still have some glitches. Since mdadm that supports bad-blocks is not out yet, you have no (official) way to create an array with bad-blocks support. So you should not suffer from those glitches. Alex. On Mon, Jul 16, 2012 at 11:56 AM, Asdo <asdo@shiftmail.org> wrote: > Right, that's the reason of my question. > Neil wrote "I probably don't want to rush it out" so that would mean that > the buggy code is not "out" yet. > So that would point to mdadm-3.3 because the bad block code of the kernel is > already "out". > However as you say the bad block code in mdadm-3.3 is very simple so it's > strange that it could be buggy. > > Now thinking at myself: if there were bugs in the mdadm-3.3 I probably have > dodged them because I was able to create the array. > However if there are known bugs in the kernel code our data is still at risk > so i'd rather ask. > FWIW I am not using mdadm-3.3 as monitoring daemon: the daemon is mdadm-3.2 > , I don't know if this "helps". > > Thank you > A. > > > > On 07/16/12 09:55, Alexander Lyakas wrote: >> >> The mdadm code only reserves some space for bad-blocks log and >> notifies the kernel that this feature is enabled during array >> creation. >> >> On Mon, Jul 16, 2012 at 10:41 AM, Asdo<asdo@shiftmail.org> wrote: >>> >>> On 07/16/12 05:41, NeilBrown wrote: >>>> >>>> and as the bad block code is >>>> clearly still buggy, I probably don't want to rush it out :-) >>> >>> >>> The bad block code is buggy... the one in the kernel or the one in >>> mdadm-3.3 >>> ? >>> 'cause I am currently using an array created with bad block log on kernel >>> 3.4.3... >>> >>> Thanks > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: On mdadm 3.2 and bad-block-log 2012-07-16 8:56 ` Asdo 2012-07-16 9:08 ` Alexander Lyakas @ 2012-07-17 1:49 ` NeilBrown 2012-07-17 8:21 ` Asdo 1 sibling, 1 reply; 10+ messages in thread From: NeilBrown @ 2012-07-17 1:49 UTC (permalink / raw) To: Asdo; +Cc: Alexander Lyakas, linux-raid [-- Attachment #1: Type: text/plain, Size: 2061 bytes --] On Mon, 16 Jul 2012 10:56:27 +0200 Asdo <asdo@shiftmail.org> wrote: > Right, that's the reason of my question. > Neil wrote "I probably don't want to rush it out" so that would mean > that the buggy code is not "out" yet. > So that would point to mdadm-3.3 because the bad block code of the > kernel is already "out". > However as you say the bad block code in mdadm-3.3 is very simple so > it's strange that it could be buggy. > > Now thinking at myself: if there were bugs in the mdadm-3.3 I probably > have dodged them because I was able to create the array. > However if there are known bugs in the kernel code our data is still at > risk so i'd rather ask. Yes, there is a degree to which your data is at risk. This is always the case with new code. If you upgrade to new -stable kernels as they become available, that should minimise your risk as any fix that could risk data or stability is backported to these -stable kernels. I don't know of any particularly serious bugs that have been found - they mostly are triggered by unusual conditions. However unusual conditions do happen. Thank you for using and testing the code. Has md found and recorded any bad blocks for you, or are your bad-block logs still empty? NeilBrown > FWIW I am not using mdadm-3.3 as monitoring daemon: the daemon is > mdadm-3.2 , I don't know if this "helps". > > Thank you > A. > > > On 07/16/12 09:55, Alexander Lyakas wrote: > > The mdadm code only reserves some space for bad-blocks log and > > notifies the kernel that this feature is enabled during array > > creation. > > > > On Mon, Jul 16, 2012 at 10:41 AM, Asdo<asdo@shiftmail.org> wrote: > >> On 07/16/12 05:41, NeilBrown wrote: > >>> and as the bad block code is > >>> clearly still buggy, I probably don't want to rush it out :-) > >> > >> The bad block code is buggy... the one in the kernel or the one in mdadm-3.3 > >> ? > >> 'cause I am currently using an array created with bad block log on kernel > >> 3.4.3... > >> > >> Thanks [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 828 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: On mdadm 3.2 and bad-block-log 2012-07-17 1:49 ` NeilBrown @ 2012-07-17 8:21 ` Asdo 2012-07-17 23:34 ` NeilBrown 0 siblings, 1 reply; 10+ messages in thread From: Asdo @ 2012-07-17 8:21 UTC (permalink / raw) To: NeilBrown; +Cc: Alexander Lyakas, linux-raid On 07/17/12 03:49, NeilBrown wrote: > On Mon, 16 Jul 2012 10:56:27 +0200 Asdo<asdo@shiftmail.org> wrote: > > Yes, there is a degree to which your data is at risk. This is always > the case with new code. If you upgrade to new -stable kernels as they > become available, that should minimise your risk as any fix that could > risk data or stability is backported to these -stable kernels. I am on kernel 3.4, that's "stable", right? > I don't know of any particularly serious bugs that have been found - they > mostly are triggered by unusual conditions. However unusual conditions do > happen. > > Thank you for using and testing the code. Has md found and recorded any bad > blocks for you, or are your bad-block logs still empty? Still empty for now They are filled only on read error + failed block rewrite, right? That will take a long time to happen... Thanks for your work ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: On mdadm 3.2 and bad-block-log 2012-07-17 8:21 ` Asdo @ 2012-07-17 23:34 ` NeilBrown 0 siblings, 0 replies; 10+ messages in thread From: NeilBrown @ 2012-07-17 23:34 UTC (permalink / raw) To: Asdo; +Cc: Alexander Lyakas, linux-raid [-- Attachment #1: Type: text/plain, Size: 1599 bytes --] On Tue, 17 Jul 2012 10:21:45 +0200 Asdo <asdo@shiftmail.org> wrote: > On 07/17/12 03:49, NeilBrown wrote: > > On Mon, 16 Jul 2012 10:56:27 +0200 Asdo<asdo@shiftmail.org> wrote: > > > > Yes, there is a degree to which your data is at risk. This is always > > the case with new code. If you upgrade to new -stable kernels as they > > become available, that should minimise your risk as any fix that could > > risk data or stability is backported to these -stable kernels. > > I am on kernel 3.4, that's "stable", right? 3.4.5 is the latest kernel in the 3.4.y stable series. It contains: - a fix for bad-block handling in RAID5 - a fix for a ref-counting bug in RAID5 that can trigger when updating the bad block list So if you are using bad-block-logs on RAID5 you should definitely upgrade to 3.4.5. If some other level ... then it is probably a good idea to upgrade anyway. > > > I don't know of any particularly serious bugs that have been found - they > > mostly are triggered by unusual conditions. However unusual conditions do > > happen. > > > > Thank you for using and testing the code. Has md found and recorded any bad > > blocks for you, or are your bad-block logs still empty? > > Still empty for now > They are filled only on read error + failed block rewrite, right? That > will take a long time to happen... They can also be filled on a read-error during recovery of one device fails. It is quite likely that none of this will happen for years. But it might happen tomorrow. > > Thanks for your work :-) NeilBrown [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 828 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-07-17 23:34 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-06-12 16:51 On mdadm 3.2 and bad-block-log Asdo 2012-07-11 9:40 ` Alexander Lyakas 2012-07-16 3:41 ` NeilBrown 2012-07-16 7:41 ` Asdo 2012-07-16 7:55 ` Alexander Lyakas 2012-07-16 8:56 ` Asdo 2012-07-16 9:08 ` Alexander Lyakas 2012-07-17 1:49 ` NeilBrown 2012-07-17 8:21 ` Asdo 2012-07-17 23:34 ` NeilBrown
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.