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? Thanks! Cheers, Ameya. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Aug 16, 2010 at 2:16 PM, Chris Mason <chris.mason@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. > > -chrisHi 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <cjb@laptop.org> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
I thought this would go to the list automatically. Here it is now. ---------- Forwarded message ---------- From: Evert Vorster <evorster@gmail.com> Date: Mon, Aug 16, 2010 at 4:04 PM Subject: Re: 2.6.36-rc1 btrfs still unstable To: Chris Ball <cjb@laptop.org> I lost a btrfs not long ago, and this is the reason I am on this list. Lucky for me, I have more than one backup of everything. Most people that use computers do not. Also, they unplug USB disks without unmounting, etc.... I don''t think the signboards are big enough. 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. I was under the impression that with atomic writes it''s impossible to mess up a file system? -Evert- On Mon, Aug 16, 2010 at 3:45 PM, Chris Ball <cjb@laptop.org> wrote:> 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 <cjb@laptop.org> > One Laptop Per Child > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >-- http://magnatune.com - Music shared the way it should be. -- http://magnatune.com - Music shared the way it should be. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <cjb@laptop.org> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Aug 16, 2010 at 10:45 AM, Chris Ball <cjb@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 > > MortenI 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> 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?Even with cheap drives, a filesystem shouldn''t die. With stuff like ZFS, you can use all sorts of crap and still live with it. Btrfs should follow that track. Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 97542685 roy@karlsbakk.net http://blogg.karlsbakk.net/ -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> 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.IMHO using btrfs in production is like playing Russian roulette - it might work and can be benifitable, but then, there''s another side of the coin... Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 97542685 roy@karlsbakk.net http://blogg.karlsbakk.net/ -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Even with cheap drives, a filesystem shouldn''t die. With stuff like ZFS, you can use all sorts of crap and still live with it. Btrfs should follow that track.Sadly that''s not true, a bit of cooperation of the hardware is needed. Both Btrfs and ZFS need to be sure that certain operations i.e. writting a modified superblock need to be physically on the disk. Some disks lie (or fail) when they are asked to write data to the disk, and both filesystems have faced filesystem inconsistencies due to this. AFAIK there is nothing the filesystem can do to avoid that. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html