Hi, I''m using the sources from [1] which I checked out today. When testing the file system with compilebench [2] I traced oops [3] (with 2 cores, SMP), [4] (single core), [5] (no smp) and [6] (no-preemt). [1] git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git [2] http://oss.oracle.com/~mason/compilebench/ [3] http://rafb.net/p/1hUnky34.html [4] http://rafb.net/p/kEGqY199.html [5] http://rafb.net/p/pAHJrV88.html [6] http://rafb.net/p/tkz92m77.html Best regards, -- Martin Bürger 1024D/27C9019B@www.edu.uni-klu.ac.at/~mbuerger/key.asc Key fingerprint = D10D 97EF 0C32 B337 5A12 0B6C 2D47 7575 27C9 019B -- 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 Fri, 2008-10-03 at 18:14 +0200, Martin Bürger wrote:> Hi, > I''m using the sources from [1] which I checked out today. When > testing the file system with compilebench [2] I traced oops [3] > (with 2 cores, SMP), [4] (single core), [5] (no smp) and [6] > (no-preemt). >> [1] > git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git > [2] http://oss.oracle.com/~mason/compilebench/ > [3] http://rafb.net/p/1hUnky34.html > [4] http://rafb.net/p/kEGqY199.html > [5] http://rafb.net/p/pAHJrV88.html > [6] http://rafb.net/p/tkz92m77.htmlHello, This is a long standing bug that so far we''ve only heard about on gentoo installs. Could you please give the attached patch a try against your sources? -chris
On Friday 03 October 2008, Chris Mason wrote:> On Fri, 2008-10-03 at 18:14 +0200, Martin Bürger wrote: > > Hi, > > I''m using the sources from [1] which I checked out today. When > > testing the file system with compilebench [2] I traced oops [3] > > (with 2 cores, SMP), [4] (single core), [5] (no smp) and [6] > > (no-preemt). > > > > > > [1] > > git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unsta > >ble.git [2] http://oss.oracle.com/~mason/compilebench/ > > [3] http://rafb.net/p/1hUnky34.html > > [4] http://rafb.net/p/kEGqY199.html > > [5] http://rafb.net/p/pAHJrV88.html > > [6] http://rafb.net/p/tkz92m77.html > > Hello, > > This is a long standing bug that so far we''ve only heard about on > gentoo installs. Could you please give the attached patch a try > against your sources?Here''s a trace after having applied the patch [1]. [1] http://rafb.net/p/8zzEfe66.html -- Martin Bürger 1024D/27C9019B@www.edu.uni-klu.ac.at/~mbuerger/key.asc Key fingerprint = D10D 97EF 0C32 B337 5A12 0B6C 2D47 7575 27C9 019B -- 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
2008/10/3 Chris Mason <chris.mason@oracle.com>:> This is a long standing bug that so far we''ve only heard about on gentoo > installs. Could you please give the attached patch a try against your > sources?I''ve got same problem, with lastest ubuntu, and my own kernel (vanilla). I can trigger disk copying ~2GB of data from my home to btrfs (65GB test partition), everytime I try. It seems easier to trigger when copying files of size > 300MB. I can give you root access to my laptop if it helps. Ciao, Gelma -- 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 Fri, 2008-10-03 at 19:16 +0200, Andrea Gelmini wrote:> 2008/10/3 Chris Mason <chris.mason@oracle.com>: > > This is a long standing bug that so far we''ve only heard about on gentoo > > installs. Could you please give the attached patch a try against your > > sources? > > I''ve got same problem, with lastest ubuntu, and my own kernel (vanilla). > I can trigger disk copying ~2GB of data from my home to btrfs (65GB > test partition), everytime I try. > > It seems easier to trigger when copying files of size > 300MB. > > I can give you root access to my laptop if it helps. > > Ciao, > GelmaOk are you also on i386 (not 64bit) -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
2008/10/3 Chris Mason <chris.mason@oracle.com>:> Ok are you also on i386 (not 64bit)yes. root@jnb:/home/gelma# head /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 14 model name : Genuine Intel(R) CPU T2500 @ 2.00GHz stepping : 8 cpu MHz : 1000.000 cache size : 2048 KB physical id : 0 siblings : 2 thanks, Gelma -- 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 Fri, 2008-10-03 at 19:10 +0200, Martin Bürger wrote:> On Friday 03 October 2008, Chris Mason wrote: > > On Fri, 2008-10-03 at 18:14 +0200, Martin Bürger wrote: > > > Hi, > > > I''m using the sources from [1] which I checked out today. When > > > testing the file system with compilebench [2] I traced oops [3] > > > (with 2 cores, SMP), [4] (single core), [5] (no smp) and [6] > > > (no-preemt). > > > > > > > > > [1] > > > git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unsta > > >ble.git [2] http://oss.oracle.com/~mason/compilebench/ > > > [3] http://rafb.net/p/1hUnky34.html > > > [4] http://rafb.net/p/kEGqY199.html > > > [5] http://rafb.net/p/pAHJrV88.html > > > [6] http://rafb.net/p/tkz92m77.html > > > > Hello, > > > > This is a long standing bug that so far we''ve only heard about on > > gentoo installs. Could you please give the attached patch a try > > against your sources? > > Here''s a trace after having applied the patch [1]. > > [1] http://rafb.net/p/8zzEfe66.html >The interesting part of this is that every file created by compilebench is filled by the same pattern 4k of ''a''. Every corruption in Martin''s trace looks the same: bad tree block start 7016996765293437281 74264576 7016996765293437281 is what we found on disk, the second number is what we expected to find. The number we found on disk is what you get when you have a u64 full of ''a''. This means that we''re overwriting metadata blocks with data blocks. I''m looking harder. -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
CONFIG_LBD was not set during my tests. After enabling it no errors whatsoever occured executing the same tests. Regards, -- Martin Bürger 1024D/27C9019B@www.edu.uni-klu.ac.at/~mbuerger/key.asc Key fingerprint = D10D 97EF 0C32 B337 5A12 0B6C 2D47 7575 27C9 019B -- 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 Fri, 2008-10-03 at 22:22 +0200, Martin Bürger wrote: [ Btrfs corruptions on i386 ]> CONFIG_LBD was not set during my tests. After enabling it no errors > whatsoever occured executing the same tests.Thank you, this is great news. I had asked Andrea to try the same thing. Toei Rei we might have finally tracked down the metadata corruptions you''ve been seeing. CONFIG_LBD turns the sector_t data type from an unsigned long into a u64. Btrfs was using it like it was always a u64, and sometimes it was overflowing. -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
2008/10/3 Chris Mason <chris.mason@oracle.com>:> On Fri, 2008-10-03 at 22:22 +0200, Martin Bürger wrote: > Thank you, this is great news. I had asked Andrea to try the same > thing. Toei Rei we might have finally tracked down the metadata > corruptions you've been seeing.Just enabling LBD seems to fix the problem here, too. I'm going to try to use the cloned partition as my new /. Is there something dangerous other the ENOSPC? Ciao, Gelma
2008/10/4 Andrea Gelmini <andrea.gelmini@gmail.com>:> 2008/10/3 Chris Mason <chris.mason@oracle.com>: >> On Fri, 2008-10-03 at 22:22 +0200, Martin Bürger wrote: >> Thank you, this is great news. I had asked Andrea to try the same >> thing. Toei Rei we might have finally tracked down the metadata >> corruptions you've been seeing. > > Just enabling LBD seems to fix the problem here, too.During a cp of ~40GB of data, some delete, a mirrordir, umount/mount, I've got these: [10214.972922] leaf ref miss for bytenr 632594432 [10250.483559] leaf ref miss for bytenr 649261056 [10250.550228] leaf ref miss for bytenr 649265152 [10250.551732] leaf ref miss for bytenr 648781824 [10250.551953] leaf ref miss for bytenr 648785920 [10250.552179] leaf ref miss for bytenr 648835072 [10250.552400] leaf ref miss for bytenr 648847360 [10250.552612] leaf ref miss for bytenr 648851456 [10250.552823] leaf ref miss for bytenr 648896512 [10250.676581] leaf ref miss for bytenr 652783616 [10250.676972] leaf ref miss for bytenr 657219584 [10285.123925] __ratelimit: 54 callbacks suppressed [10285.123934] leaf ref miss for bytenr 642347008 [10285.138480] leaf ref miss for bytenr 617934848 [10285.151323] leaf ref miss for bytenr 617992192 [10285.151796] leaf ref miss for bytenr 642281472 [10285.152341] leaf ref miss for bytenr 642285568 [10285.153285] leaf ref miss for bytenr 642289664 [10285.154792] leaf ref miss for bytenr 642392064 [10285.155524] leaf ref miss for bytenr 642396160 [10285.156625] leaf ref miss for bytenr 642400256 [10285.157611] leaf ref miss for bytenr 642404352 [10318.687782] __ratelimit: 29 callbacks suppressed [10318.687789] leaf ref miss for bytenr 678326272 [10318.704306] leaf ref miss for bytenr 678330368 [10318.704472] leaf ref miss for bytenr 678338560 [10318.729985] leaf ref miss for bytenr 678342656 [10318.755394] leaf ref miss for bytenr 678346752 [10318.763202] leaf ref miss for bytenr 678313984 [10318.773391] leaf ref miss for bytenr 678318080 [10318.773702] leaf ref miss for bytenr 678354944 [10318.777391] leaf ref miss for bytenr 678359040 [10318.777675] leaf ref miss for bytenr 678363136 [10356.669498] __ratelimit: 11 callbacks suppressed [10356.669505] leaf ref miss for bytenr 660512768 [10356.669847] leaf ref miss for bytenr 660525056 [10356.670201] leaf ref miss for bytenr 660508672 [10356.670350] leaf ref miss for bytenr 660602880 [10356.714106] leaf ref miss for bytenr 689676288 [10356.808036] leaf ref miss for bytenr 681152512 [10427.571182] leaf ref miss for bytenr 689090560 [10668.182699] leaf ref miss for bytenr 879042560 [10668.182864] leaf ref miss for bytenr 879046656 [10668.187659] leaf ref miss for bytenr 897560576 [10668.212862] leaf ref miss for bytenr 876032000 [10711.367564] device fsid 5d41ce5f92d3ade5-fe90f7c6d4868c8f devid 1 transid 302 /dev/mapper/VG-btrfs [10835.194165] device fsid 5d41ce5f92d3ade5-fe90f7c6d4868c8f devid 1 transid 308 /dev/mapper/VG-btrfs [10936.182217] space info full 1 [11165.099901] leaf ref miss for bytenr 450011136 [11165.159859] leaf ref miss for bytenr 463335424 [11165.256534] leaf ref miss for bytenr 463851520 [11165.259397] leaf ref miss for bytenr 463831040 [11165.268931] leaf ref miss for bytenr 467079168 [11913.501914] leaf ref miss for bytenr 444170240 [11913.502217] leaf ref miss for bytenr 444190720 [11913.519761] leaf ref miss for bytenr 444149760 [11913.621481] leaf ref miss for bytenr 469667840 [11913.621738] leaf ref miss for bytenr 469696512 Ciao, Gelma
On Sat, Oct 04, 2008 at 02:15:53AM +0200, Andrea Gelmini wrote:> 2008/10/4 Andrea Gelmini <andrea.gelmini@gmail.com>: > > 2008/10/3 Chris Mason <chris.mason@oracle.com>: > >> On Fri, 2008-10-03 at 22:22 +0200, Martin Bürger wrote: > >> Thank you, this is great news. I had asked Andrea to try the same > >> thing. Toei Rei we might have finally tracked down the metadata > >> corruptions you''ve been seeing. > > > > Just enabling LBD seems to fix the problem here, too. > > During a cp of ~40GB of data, some delete, a mirrordir, umount/mount, > I''ve got these: > [10214.972922] leaf ref miss for bytenr 632594432These are safe, I''m removing them. -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 Sat, Oct 04, 2008 at 12:09:08AM +0200, Andrea Gelmini wrote:> 2008/10/3 Chris Mason <chris.mason@oracle.com>: > > On Fri, 2008-10-03 at 22:22 +0200, Martin Bürger wrote: > > Thank you, this is great news. I had asked Andrea to try the same > > thing. Toei Rei we might have finally tracked down the metadata > > corruptions you''ve been seeing. > > Just enabling LBD seems to fix the problem here, too. > > I''m going to try to use the cloned partition as my new /. > Is there something dangerous other the ENOSPC?We don''t have known big bugs right now, but you''ll need to use another FS on /boot. -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 Fri, Oct 3, 2008 at 5:31 PM, Chris Mason <chris.mason@oracle.com> wrote:> > We don''t have known big bugs right now, but you''ll need to use another > FS on /boot.Is a patch to grub and/or grub2 on the roadmap for r/o btrfs support once the disk format stabilizes? -- Jeff Schroeder Don''t drink and derive, alcohol and analysis don''t mix. http://www.digitalprognosis.com -- 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 Fri, 2008-10-03 at 20:41 -0700, Jeff Schroeder wrote:> On Fri, Oct 3, 2008 at 5:31 PM, Chris Mason <chris.mason@oracle.com> wrote: > > > > We don''t have known big bugs right now, but you''ll need to use another > > FS on /boot. > > Is a patch to grub and/or grub2 on the roadmap for r/o btrfs support once the > disk format stabilizes? >Yes, it actually wouldn''t be a bad project for someone looking to get started on btrfs. -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
2008/10/4 Chris Mason <chris.mason@oracle.com>:>> I''m going to try to use the cloned partition as my new /. >> Is there something dangerous other the ENOSPC? > > We don''t have known big bugs right now, but you''ll need to use another > FS on /boot.I use initd, so no problem. Anyway, I started using btrfs for my /home (before it was Reiserfs3). Well, after few days of usage, the good news is about no problem like crash, file corruption, and so on. It also worked well with TuxOnIce, with a lot of suspend/resume cycle. The bad news is about load average. In normal session (WindowMaker, Firefox, Kopete, Skype, Konsole, Evince, Azureus, Evolution, K3B) I''ve a lot higher load average respect Reiserfs3. The worst is using mirrordir to backup /home on external device (load avg > 10). Is it a normal work in progress, or does it happens only to me? My /home is over dm-crypt, by the way. Thanks a lot for your time, Gelma -- 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 Tue, 2008-10-07 at 13:31 +0200, Andrea Gelmini wrote:> 2008/10/4 Chris Mason <chris.mason@oracle.com>: > >> I''m going to try to use the cloned partition as my new /. > >> Is there something dangerous other the ENOSPC? > > > > We don''t have known big bugs right now, but you''ll need to use another > > FS on /boot. > > I use initd, so no problem. > Anyway, I started using btrfs for my /home (before it was Reiserfs3). > Well, after few days of usage, the good news is about no problem like > crash, file corruption, and so on. It also worked well with TuxOnIce, > with a lot of suspend/resume cycle. The bad news is about load > average. In normal session (WindowMaker, Firefox, Kopete, Skype, > Konsole, Evince, Azureus, Evolution, K3B) I''ve a lot higher load > average respect Reiserfs3. The worst is using mirrordir to backup > /home on external device (load avg > 10). > Is it a normal work in progress, or does it happens only to me? > My /home is over dm-crypt, by the way. >Btrfs does use more cpu than reiserfs will because of the checksumming, and you have dm-crypt using CPU as well. Is the system unresponsive during the high load? The load on linux is somewhat strange because it reflects both the number of procs waiting on IO and the number using CPU. Running top and looking at the process states will help figure out which one is the cause ''D'' means IO and ''R'' means CPU. -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
2008/10/7 Chris Mason <chris.mason@oracle.com>:> Btrfs does use more cpu than reiserfs will because of the checksumming,I don''t think this is the problem. I mean, in same condition, with Reiserfs3, I stay between 0.85 - 1.50 load avg. Now I easily go from 5 - 10. It''s hard to believe so much overhead just for CRC. Anyway, can I safely mount my /home disabling CRC? I read it about time before.> and you have dm-crypt using CPU as well. Is the system unresponsive > during the high load?not exactly. it became slugghish. so, things that was zero-wait, now may have seconds of delay. something similar a "make -j"... now I have doubled the space of the logical volume, and things seems better (now, loadavg is not going over 4, doing the mirrordir test). anyway, I have to use it almost one day, to have a clear idea.> The load on linux is somewhat strange because it reflects both the > number of procs waiting on IO and the number using CPU. Running top and > looking at the process states will help figure out which one is the > cause ''D'' means IO and ''R'' means CPU.yes. well, the strange things is the system is faster than before doing write. but looking at top (I use htop, but it doesn''t matter), it doesn''t seem something process related, but seems kernel alway busy doing something I can''t figure out. are there some tests I can run just to have some raw number to try to explain this? thanks a lot for your time, Gelma -- 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 Tue, 2008-10-07 at 17:04 +0200, Andrea Gelmini wrote:> 2008/10/7 Chris Mason <chris.mason@oracle.com>: > > Btrfs does use more cpu than reiserfs will because of the checksumming, > I don''t think this is the problem. I mean, in same condition, with Reiserfs3, > I stay between 0.85 - 1.50 load avg. > Now I easily go from 5 - 10. > It''s hard to believe so much overhead just for CRC. > Anyway, can I safely mount my /home disabling CRC? I read it about time before.Yes, you can mount -o nodatasum> > > and you have dm-crypt using CPU as well. Is the system unresponsive > > during the high load? > not exactly. it became slugghish. so, things that was zero-wait, now > may have seconds of delay. > something similar a "make -j"... > now I have doubled the space of the logical volume, and things seems > better (now, loadavg is not going over 4, doing > the mirrordir test). > anyway, I have to use it almost one day, to have a clear idea.Ok, its important to understand which parts of the FS are using so much cpu. It is pretty easy to tell based on the output of top (which procs are consuming the most time).> > > The load on linux is somewhat strange because it reflects both the > > number of procs waiting on IO and the number using CPU. Running top and > > looking at the process states will help figure out which one is the > > cause ''D'' means IO and ''R'' means CPU. > yes. > well, the strange things is the system is faster than before doing > write. but looking at top (I use htop, but it doesn''t matter), it > doesn''t seem something process related, but seems kernel alway busy > doing something I can''t figure out. > > are there some tests I can run just to have some raw number to try to > explain this?Which procs are using the most time in top? -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
2008/10/7 Chris Mason <chris.mason@oracle.com>:> Ok, its important to understand which parts of the FS are using so much > cpu. It is pretty easy to tell based on the output of top (which procs > are consuming the most time).Well, it''s not about a process doing something intensive, but different procs doing a little i/o. Azurues (reading and writing no more than 40KB/s), Firefox (I''ve got cache in tmpfs, but history & co. in ~/.mozilla), IM (logs chat), Vim, and so on. So, usually, I see process in D (for too much time, I would say). I though "maybe it takes too long to find free space", I was at 80% full. A couple of hours ago I doubled the free space (now I am using the 33% of the partition). Things are not perfect, but a lot better. Loadavg is < 1, and things seems responsive. Anyway, I''ll wait some days and I''ll see. I need to use it for sometime to have a good idea. Less free space could be the problem? Ciao, Gelma -- 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
2008/10/7 Andrea Gelmini <andrea.gelmini@gmail.com>:> Less free space could be the problem?Well, I can say more free space makes load avg lesser. Anyway, now I''ve got a freeze (you can see the dmesg in attach). It seems related with che last file I''m downloading with Azureus. If I restart it (azureus), after a while it crashes again (kernel). Well, is it enough to remove the file? Or move it? Or is it better if I restore my backup? Thanks a lot, Gelma -- 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 Wed, 2008-10-08 at 23:51 +0200, Andrea Gelmini wrote:> 2008/10/7 Andrea Gelmini <andrea.gelmini@gmail.com>: > > Less free space could be the problem? > > Well, I can say more free space makes load avg lesser. > Anyway, now I''ve got a freeze (you can see the dmesg in attach). > It seems related with che last file I''m downloading with Azureus. > If I restart it (azureus), after a while it crashes again (kernel). > > Well, is it enough to remove the file? Or move it? Or is it better if > I restore my backup?Please post the crash, that''s the easiest way to figure things out. -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
2008/10/9 Chris Mason <chris.mason@oracle.com>:> Yan, > > Can these leaf ref miss warnings trigger corruptions? I thought not but > its clear there is some metadata corruption here: > > Andrea, how exactly did you trigger this?Nothing in particular, usual work session on my laptop. It seems to be it was a problem with a newly created torrent file. Well, no deep debug, simply some minutes after Azureus started it crashed (kernel), always. So I take new last file, copyed to tmpfs (without errors reading), and re-copyed to btrfs. The problem disappeared. Part of file was corrupted, but there was the crash, azureus caching, and so on. Anyway, comparing my /home with the external backup, I found no problem. ''Til now I have no evidence of data/metadata corruption. Thanks a lot, Andrea -- 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
2008/10/9 Yan Zheng <zheng.yan@oracle.com>:> Andrea, did you create swap file on btrfs?No, but Azureus (see my other email) plays a lot with holes. Thanks a lot, Andrea -- 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
2008/10/10 Andrea Gelmini <andrea.gelmini@gmail.com>:> 2008/10/9 Yan Zheng <zheng.yan@oracle.com>: >> Andrea, did you create swap file on btrfs? > No, but Azureus (see my other email) plays a lot with holes.Well, I try to extend my previous reply (in the meanwhile it crashed again (kernel) with a newly added file). I''ve got no "unsual" usage of my btrfs partition (is a /home on a logical volume, over a dm-crypted /dev/sda3 partition). The process able to trigger the crash is Azureus. The "unusual" work of it, respect the other programs I run, is its creation of file with lots of hole. When I start to download movies (ehm... iso images of linux distribution...), it does this: first chunk (1~4MB) --- big big big holes (for ~1GB) --- last chunk (1~4MB) then, while downloading, it replaces holes with real data (in a random way, of course). Well, I could try to allocate all space at the time creation. Anyway, today I''ll switch to 2.6.27 and new btrfs layout, so I postpone this try after. Thanks a lot for your time, Andrea -- 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