Hi, I started using btrfs yesterday and used the version that comes with 2.6.29-rc8. The main reason I wanted to try btrfs is that because I am running on SSD''s and the normal wear leveling algorithm of this SSD (MTRON 7535) failed terribly with xfs. (SSD''s wore out in 2 months) I have a 64GB ssd mounted with ''-o noatime'' and ''-o ssd''. The load is MySQL with 300-400 inserts/sec 24/7 on a large database with a lot of indexes. Attached is the trace I got this morning. The system ran fine for about 16 hours :) -- Met vriendelijke groet, Tom van Klinken ISP Services BV http://www.isp-services.nl/contact
On Tue, 2009-03-24 at 15:41 +0100, Tom van Klinken / ISP Services BV wrote:> Hi, > > I started using btrfs yesterday and used the version that comes with > 2.6.29-rc8. > > The main reason I wanted to try btrfs is that because I am running on > SSD''s and the normal wear leveling algorithm of this SSD (MTRON 7535) > failed terribly with xfs. (SSD''s wore out in 2 months) > > I have a 64GB ssd mounted with ''-o noatime'' and ''-o ssd''. > > The load is MySQL with 300-400 inserts/sec 24/7 on a large database with > a lot of indexes. > > Attached is the trace I got this morning. The system ran fine for about > 16 hours :) >This is a metadata enospc oops. You actually had about 400MB free but it was pinned down and waiting for a commit to free it all. There is definitely more work to do on the metadata enospc side of things. One possible problem is that your disk is full of data block groups and more metadata groups are required. I''ll work on some more metadata enospc patches this week. -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
Hi Chris, Chris Mason wrote:> On Tue, 2009-03-24 at 15:41 +0100, Tom van Klinken / ISP Services BV > wrote: >> <CUT> > > This is a metadata enospc oops. You actually had about 400MB free but > it was pinned down and waiting for a commit to free it all. >Today I had a similar issue. See attached kernel trace. I''m quite sure the filesystem is not full (I have around 15GB of free space). Is their anything I can test/do? -- Met vriendelijke groet, Tom van Klinken ISP Services BV http://www.isp-services.nl/contact
On Tue, 2009-03-31 at 13:26 +0200, Tom van Klinken / ISP Services BV wrote:> Hi Chris, > > Chris Mason wrote: > > On Tue, 2009-03-24 at 15:41 +0100, Tom van Klinken / ISP Services BV > > wrote: > >> <CUT> > > > > This is a metadata enospc oops. You actually had about 400MB free but > > it was pinned down and waiting for a commit to free it all. > > > Today I had a similar issue. See attached kernel trace. > > I''m quite sure the filesystem is not full (I have around 15GB of free > space). > > Is their anything I can test/do? > > plain text document attachment (btrfc-trace2.txt) > Mar 31 00:20:07 db03b btrfs searching for 4096 bytes, num_bytes 4096, loop 2, allowed_alloc 0 > Mar 31 00:20:07 db03b btrfs allocation failed flags 36, wanted 4096 > Mar 31 00:20:07 db03b space_info has 204537856 free, is fullWell, the problem is that you''ve filled up the metadata areas of your FS. So, even though the FS reads 15GB free, the space available for metadata is full. I''m working on some patches to help. -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