Re: 2.6.36-rc1 btrfs still unstable
Le 25 août 2010 à 18:57, Johannes Hirte a écrit: the other big question is: Is btrfs with 2.6.36 really rockstable and ready to use in productive environments? I don't think so. There is at least one checksum bug and ENOSPC problems are also still present. I am planning to put 2 dedicated web hosting servers in production (backuped every day), with 2.6.34.5 vanilla kernel. I also use btrfs on a 2.6.34 kernel on the backup server (rsync) for some time. -- Xavier Nicollet -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36-rc1 btrfs still unstable
On Monday 16 August 2010 16:17:54 Morten P.D. Stevens wrote: Hi Chris, the other big question is: Is btrfs with 2.6.36 really rockstable and ready to use in productive environments? Thanks Morten I don't think so. There is at least one checksum bug and ENOSPC problems are also still present. regards, Johannes -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36-rc1 btrfs still unstable
On Mo 16.Aug'10 at 11:45:29 -0400, Chris Ball wrote: Note that Btrfs does not yet have a fsck tool that can fix errors. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power. This will be fixed when the fsck tool is ready. Shouldn't this (surprising) information be in the kernel config option too? I am testing a btrfs /home on my laptop since January 2010, and somehow I missed this particular risk. As I knew about the others, I do backups almost everyday, but anyway. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36-rc1 btrfs still unstable
On Mon, Aug 16, 2010 at 10:45 AM, Chris Ball c...@laptop.org wrote: Note that Btrfs does not yet have a fsck tool that can fix errors. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power. This will be fixed when the fsck tool is ready. Um, is this related to disks lying about actually writing to spinning rust, or can this happen on disks that do so properly? -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36-rc1 btrfs still unstable
On Mon, Aug 16, 2010 at 11:46:22AM +0300, Ameya Palande wrote: Hi Chris, Today I was checking the Kconfig option for btrfs and it still says, Btrfs filesystem (EXPERIMENTAL) Unstable disk format I remember that some time back we had discussion about this on meego-dev mailing list: http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg04881.html In case if you have forgotten about this, then can we still change this for 36-rc2? Yes, I'll go ahead and send this one in. I've spent a great deal of time trying to nail down the interaction between raid56 stripe size and adding/removing volumes from the FS (basically restriping the raid). The end result just isn't as user friendly as I wanted yet, but the raid code is holding up very well. -chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 2.6.36-rc1 btrfs still unstable
On Mon, Aug 16, 2010 at 2:16 PM, Chris Mason chris.ma...@oracle.com wrote: On Mon, Aug 16, 2010 at 11:46:22AM +0300, Ameya Palande wrote: Hi Chris, Today I was checking the Kconfig option for btrfs and it still says, Btrfs filesystem (EXPERIMENTAL) Unstable disk format I remember that some time back we had discussion about this on meego-dev mailing list: http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg04881.html In case if you have forgotten about this, then can we still change this for 36-rc2? Yes, I'll go ahead and send this one in. I've spent a great deal of time trying to nail down the interaction between raid56 stripe size and adding/removing volumes from the FS (basically restriping the raid). The end result just isn't as user friendly as I wanted yet, but the raid code is holding up very well. -chris Hi Chris, the other big question is: Is btrfs with 2.6.36 really rockstable and ready to use in productive environments? Thanks Morten -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36-rc1 btrfs still unstable
Hi, the other big question is: Is btrfs with 2.6.36 really rockstable and ready to use in productive environments? No, certainly not until there's a working fsck tool -- at the moment it's rather easy to kill a btrfs by just losing power. I just added a paragraph to the main page of the wiki about this, since we've had a few people on IRC express surprise that their filesystem aren't fixable after power loss. Feel free to reword: Note that Btrfs does not yet have a fsck tool that can fix errors. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power. This will be fixed when the fsck tool is ready. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36-rc1 btrfs still unstable
Hi, I don't think the signboards are big enough. Sure; that's why I tried to make one of them larger. Most people assume that there is some way of fixing a broken file system, and finding out the btrfs does not have one usually is quite surprising and just a little too late. Agreed, that's my experience from the IRC channel. I was under the impression that with atomic writes it's impossible to mess up a file system? Yes, we're not seeing data corruption, we're correctly reporting that the transid of the data block doesn't match the transid in the parent node's pointer, which means that some writes went missing. Then we're hitting a BUG() as a result, which hangs. I don't know what the right way of dealing with this is going to be, but answers like pretend the lost writes never happened and sync the transids, or do something other than BUG() on verify_parent_transid() failure sound plausible. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36-rc1 btrfs still unstable
On Lunes, 16 de Agosto de 2010 17:45:29 Chris Ball escribió: Note that Btrfs does not yet have a fsck tool that can fix errors. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power. This will be fixed when the fsck tool is ready. But doesn't this happen only with cheap disks that don't honour barriers correctly? -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36-rc1 btrfs still unstable
On 16/08/10 18:46, Ameya Palande wrote: Today I was checking the Kconfig option for btrfs and it still says, Btrfs filesystem (EXPERIMENTAL) Unstable disk format I have a memory that there was still a possible disk format change in the pipeline, am I misremembering, Chris M. ? cheers! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
