Re: [RFC] Move all btrfs command to only one command
diff --git a/btrfs_cmds.c b/btrfs_cmds.c
index e112902..271ca89 100644
--- a/btrfs_cmds.c
+++ b/btrfs_cmds.c
@@ -497,7 +497,7 @@ static void print_one_uuid(struct btrfs_fs_devices
*fs_devices)
devs_found++;
}
if (devs_found < total) {
- printf("\t*** Some devices missing\n");
+ printf("\t L1: Some devices missing\n");
}
printf("\n");
}
diff --git a/btrfs.c b/btrfs.c
index 4d263c4..b3a087e 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -134,12 +135,13 @@ static void help(char *np)
{
struct Command *cp;
- printf("Usage:\n");
+ printf("VFS-2593-A %s\n", BTRFS_BUILD_VERSION);
+ printf("\nNo matter where you go, there you are.\n");
+ printf("\nUsage:\n");
for( cp = commands; cp->verb; cp++ )
print_help(np, cp);
- printf("\n\t%s help|--help|-h\n\t\tShow the help.\n",np);
- printf("\n%s\n", BTRFS_BUILD_VERSION);
+ printf("\n\t%s help|--help|-h\n\t\tShow help.\n",np);
}
I don't like the look of using errno.h at this time, so attached is
the error code file extracted from the help file and an additional
patch for label support. There may be leftover typos especially in the
errorcode.txt file so it might be nice to have a read-over. Does
someone want to get on strings translation? :)
On 8/21/10, James Smith wrote:
> excuse me, errno.h.
>
> On 8/21/10, James Smith wrote:
>> Thanks.
>>
>> What about stderr.h?
>>
>> On 8/21/10, Goffredo Baroncelli wrote:
>>> On Saturday, 21 August, 2010, James Smith wrote:
>>> [...]
I'll look at a error.txt file (after finding convention) and also
update the man. In regards to shortening of dev/device -- is this
really neccessary? And what harm does this cause in the first place?
In device add-delete functionality.
>>>
>>> Make sense to rename in for the "btrfs add/delete"
>>> commands
>>>
>>>
On 8/20/10, Josh Berry wrote:
> On Fri, Aug 20, 2010 at 12:00, Andreas Philipp
> wrote:
>> On 20.08.2010 20:49, Josh Berry wrote:
>>>
>>> On Fri, Aug 20, 2010 at 11:34, Andreas Philipp
>>> wrote:
On 20.08.2010 20:27, Josh Berry wrote:
>
> On Fri, Aug 20, 2010 at 05:03, Goffredo
>>> Baroncelli
> wrote:
>>
>> On Thursday, 19 August, 2010, James Smith wrote:
>>>
>>> This patch randomizes the error codes and also fixes up some
>>> typos
>>
>> including
>>>
>>> capitalization in the output.
>>>
>>> It would almost be nice to see a translation effort for the
>>> tool
>>> as
>>> well.
>
> [...]
>>
>> + fprintf(stderr, "ERR-A.11: in command
>> '");
>>
>> I am not against this kind of error codes, but I prefer
>>
>> + fprintf(stderr, "Error 'ERR-A.11' in
>> command
>> '");
>
> As a layman/end user, I disagree. The former format is easier
> for
> shell scripts and the like to parse -- the error code can be
>>> extracted
> with a simple "cut -d: -f1".
This makes no difference. A simple `cut -d " " -f1` would do the
job
>>> in
the
second case.
>>>
>>> I think you meant -f2, and that still leaves the quotes hanging
>>> around. So you'd need to cut -d" " -f2 |tr -d "'" . It's not a
>>> big
>>> deal either way, I just think the former is easier to work with.
>>
>> Sorry, of course -f2. But why not simply cut -d "'" -f 2?
>
> Oh right, good point. :) Though as Goffredo said, using the error
> code is probably better anyway.
>
> -- Josh
> --
> 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
>
--
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
>>>
>>>
>>> --
>>> gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo)
>>>
>>> Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
>>> --
>>> 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
>>>
>>
>
Error code listing for btrfs.
A) Clone btrfs disk
A1: Error accessing the inputted subvolume.
A2: The inputted subvolume is not recognized as a subvolume.
A3: Passed argument is not a directory.
B) Snapshot btrfs disk
B1: Incorrect snapshot name has been en
Re: The "The status of btrfsck" thread
Thanks chris, and that's wonderful! Lemme just hope silent corruption won't kill me by then (I had to force my computer to turn off a couple of times (but that was so long ago)) Looking forward to the releases. On Thu, Aug 26, 2010 at 7:57 PM, Chris Mason wrote: > On Thu, Aug 26, 2010 at 03:43:52AM -0500, Chester wrote: >> Hi, I'm aware that btrfs doesn't have a functioning fsck tool that >> fixes errors. >> I was just wondering (I'm sure many are, also) if there is a working >> btrfsck somewhere in the pipeline. >> If there is some sort of rough estimate to when it'll be available, >> please state it here. >> >> If you're not confident about any release date, it's no big deal. I >> just want an organized place >> to sift through things regarding btrfsck (since it's pretty crucial) > > We're still actively developing it. I don't have a release date planned > yet but we should have betas coming out over the next few months. > > -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: What is the status of versioned builds for btrfs-progs
On 08/07/2010 05:48 AM, Joe Peterson wrote:
I just had a bug reported (assigned to me) in the Gentoo Linux distro
about a missing option ("-D") in btrfscrl. Looking into it, it
appears this feature is post the 0.19 tag of btrfs-progs. I would
like to get a more up-to-date btrfs-progs into Gentoo, but I would
like to follow the upstream versioning (well, we can do "live" builds,
but those do not give a predictable/persistent source snapshot). 0.19
was tagged 13 months ago, according to the git tree. Are there plans
to release newer versions?
Thanks! Joe
--
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
I just had a similar assigned bug in MeeGo distro too. I have to use a
GIT snapshot as an upgrade.
Regards,
Zhu Yanhai
--
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: The "The status of btrfsck" thread
On Thu, Aug 26, 2010 at 03:43:52AM -0500, Chester wrote: > Hi, I'm aware that btrfs doesn't have a functioning fsck tool that > fixes errors. > I was just wondering (I'm sure many are, also) if there is a working > btrfsck somewhere in the pipeline. > If there is some sort of rough estimate to when it'll be available, > please state it here. > > If you're not confident about any release date, it's no big deal. I > just want an organized place > to sift through things regarding btrfsck (since it's pretty crucial) We're still actively developing it. I don't have a release date planned yet but we should have betas coming out over the next few months. -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
> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Poor creat/delete files performance
On Thu, Aug 26, 2010 at 06:07:55PM +0800, Miao Xie wrote: > On Wed, 18 Aug 2010 20:57:43 -0400, Chris Mason wrote: > >Since the files are empty, and we aren't doing enough files to trigger > >IO, it is really benchmarking the cost of the btree insertions/removals > >in comparison with ext4. I do expect this to be higher because btrfs is > >indexing the directories twice (once by name and once by sequence number > >for faster backups). > > > >On my machine: > > > >Btrfs defaults: > > > >Create files: > > Total files: 5 > > Total time: 0.916680 > > Average time: 0.18 > >Delete files: > > Total files: 5 > > Total time: 1.329892 > > Average time: 0.27 > > > >Ext4: > > > >creat_unlink 5 > >Create files: > > Total files: 5 > > Total time: 0.718190 > > Average time: 0.14 > >Delete files: > > Total files: 5 > > Total time: 0.308815 > > Average time: 0.06 > > > >We're definitely slower than ext4, but as Ric's benchmarks show things > >tend to tilt in our favor once IO is actually done. > > > >There are two big things that would help fix this performance gap: > >Switching the extent buffer rbtree into a radix tree (esp a lockless > >radix tree), and delaying insertion of the inode so that we can do more > >in btree operations in bulk. > > > >The radix tree is a much easier and more contained project. > > The type of the radix tree's key is "unsigned long", but the type of the > extent buffer's key is "u64". That is we can't use the radix tree instead of > rbtree on the 32-bits boxs. So we can't switching the extent buffer rbtree > into a radix tree. Right, but the key is just the byte number offset from 0. The extent buffers are backed by pages, and the pages are allocated off the metadata inode's address space, which is backed by a radix tree. You can try using the (bytes offset >> PAGE_CACHE_SHIFT). The problem you might hit is the radix tree is tuned pretty hard now for the page cache. Another option is to attach the extent buffers to page->private, and use the page cache's radix tree (remove the rbtree completely). For blocksize > pagesize, we could only put the first page in each block into the page cache, and just tie the rest of the off the extent buffer. But, if you get the 4K metadata block size part working, I can cram in the larger block sizes pretty easily now. -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
> 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 r...@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 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? 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 r...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
On Thu, 26 Aug 2010, Christoph Lameter wrote: > > Because we can remove the flag, remove branches from the page allocator > > slowpath, and none of these allocations actually are dependent on > > __GFP_NOFAIL since they are all under PAGE_ALLOC_COSTLY_ORDER. > > Then we can simply remove __GFP_NOFAIL? Functions are only needed for > higher order allocs that can fail? > Yes, that's the intent. We'd like to add the WARN_ON_ONCE(get_order(size) >= PAGE_ALLOC_COSTLY_ORDER) warning, though, so we're ensured that redefinition of that #define doesn't cause allocations to fail to that don't have appropriate error handling or future callers use higher order allocs. The _nofail() functions help that and do some due diligence in ensuring that we aren't changing gfp flags based only on the current page allocator implementation which may later change with very specialized corner cases. -- 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: machine gets unresponsive during btrfs balance
Johannes Hirte, Thu, 26 Aug 2010 18:38:30 +0200: > On Thursday 26 August 2010 15:39:25 Andreas Philipp wrote: >> On 26.08.2010 15:27, Johannes Hirte wrote: >> > Looks like another manifestation of the csum bug. Are you able to >> > read all files from the affected volume? Did you tried a balance with >> > an 2.6.34 kernel after the test with 2.6.35? >> > >> Till now I did not see any unreadable files but I did not do a complete >> test. No, I did not try to balance with an 2.6.34 kernel. If it helps I >> can switch back and try. > > I hope it helps to localize the error. It's still not clear where this > starts an what kernels are affected. > > regards, > Johannes I have now as well a volume that shows the csum bug and no, I cannot read all files. Please let me know if I can test something. Kernel 2.6.35- gentoo-r4 Regards Lubos -- 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: machine gets unresponsive during btrfs balance
On Thursday 26 August 2010 15:39:25 Andreas Philipp wrote: > On 26.08.2010 15:27, Johannes Hirte wrote: > > Looks like another manifestation of the csum bug. Are you able to read all > > files from the affected volume? Did you tried a balance with an 2.6.34 > > kernel > > after the test with 2.6.35? > > > Till now I did not see any unreadable files but I did not do a > complete test. No, I did not try to balance with an 2.6.34 kernel. If > it helps I can switch back and try. I hope it helps to localize the error. It's still not clear where this starts an what kernels are affected. 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: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
On Wed, 25 Aug 2010, David Rientjes wrote: > Because we can remove the flag, remove branches from the page allocator > slowpath, and none of these allocations actually are dependent on > __GFP_NOFAIL since they are all under PAGE_ALLOC_COSTLY_ORDER. Then we can simply remove __GFP_NOFAIL? Functions are only needed for higher order allocs that can fail? -- 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: machine gets unresponsive during btrfs balance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26.08.2010 15:27, Johannes Hirte wrote: > On Saturday 14 August 2010 00:11:55 Andreas Philipp wrote: >> On 12.08.2010 10:04, Yan, Zheng wrote: >>> On Thu, Aug 12, 2010 at 3:14 PM, Andreas Philipp >>> wrote: >>> Hi, I am using a btrfs filesystem created with raid0 for data and metadata for (temporary) storage of tv recordings from my vdr. The filesystem was created under kernel version 2.6.34. An initial btrfs balance command succeeded. Since I upgraded to 2.6.35-rcX and 2.6.35 btrfs balance no longer finishes but puts the machine in some unresponsive state. Unfortunately, I do not see any kernel oops or other debug information because even the display freezes. The last thing that happens are that those two lines are written to /var/log/messages: Aug 11 21:42:23 thor kernel: btrfs: found 62911 extents Aug 11 21:42:24 thor kernel: btrfs: relocating block group 1723913469952 flags 9 After that the machine becomes immediately unresponsive. As I did not see anything that might be related to my problem in the changelog for 2.6.35.1 I did not try again with this version. >>> Do you have more than one machines? would you please setup netconsole >>> to see what happen. >>> >> I have reproduced the error on v2.6.35.1 and recorded all kernel output >> with netconsole. The interesting point is that this time the machine did >> not crash but the btrfs balance segfaulted at exact the same position >> where the previous crashes had happened. > > Looks like another manifestation of the csum bug. Are you able to read all > files from the affected volume? Did you tried a balance with an 2.6.34 kernel > after the test with 2.6.35? > Till now I did not see any unreadable files but I did not do a complete test. No, I did not try to balance with an 2.6.34 kernel. If it helps I can switch back and try. Yours, Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMdm6MAAoJEJIcBJ3+Xkgi9vUQALX7V6fOs+DJR9NGRr21uY1a /tFj5e1r71Mryn6uFcnb2Iukf6oNirxc3n4XcSgfel/GppTPAt+s8a3jS048SNa1 XpPhpuA5j9vtPns46ZR5Bg9rTtAIa7oDO8Ko2lewnHcrZN9qoGyroTz+eIzqv/U/ N8BmGTKTE1TwKfETE8jVXXHvsQuV6vYeOJqtWzPkETw9gldHThTSvr3pl7+46yFT iCv5n/IHsdAyeZpSJm1Jp3xxAGZJsrkhoKiyNcHHt7+UshcKpFYky4lOCAlDgpPO quZhEHiYKUeHGYb8vueaebCgy2panrYcnEgwoGkI7XLPvTlWY/5uUgV/54rlUdwi jqo+zgyNaBnEwUkqTAPzqZQBYb7XA5uJS7UchFhf5rpgFZeEX+gUnNYtEtUkkYLk 9vAAeXl8OyNJnBAH97/FBpRw0nVYpXeuE8/dvc1TfbHDjkOQLlgEYg3T4PW+NgsV IwVOChoFPEmyFndAvONphTmUQjzGMJu2Y+3p9D7ZDRQOo8AHjGrErWPY+zGkZkd1 MtFCIKeTyOoR+13U4xAxi+2alGf7UE0jdxoGMQPnh7COjOYpUgMt1zFnksxn6yY+ RcFEWJSoBkOPMePxzJUTOCVb/Qr4V6HCJNEylBxF1VsECAOkjTSxl4XTAXrLKYVu pllFS2PYozhZMoKrDKQE =ldPn -END PGP SIGNATURE- -- 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: machine gets unresponsive during btrfs balance
On Saturday 14 August 2010 00:11:55 Andreas Philipp wrote: > On 12.08.2010 10:04, Yan, Zheng wrote: > > On Thu, Aug 12, 2010 at 3:14 PM, Andreas Philipp > > wrote: > > > >> Hi, > >> > >> I am using a btrfs filesystem created with raid0 for data and metadata > >> for (temporary) storage of tv recordings from my vdr. The filesystem was > >> created under kernel version 2.6.34. An initial btrfs balance command > >> succeeded. Since I upgraded to 2.6.35-rcX and 2.6.35 btrfs balance no > >> longer finishes but puts the machine in some unresponsive state. > >> Unfortunately, I do not see any kernel oops or other debug information > >> because even the display freezes. The last thing that happens are that > >> those two lines are written to /var/log/messages: > >> Aug 11 21:42:23 thor kernel: btrfs: found 62911 extents > >> Aug 11 21:42:24 thor kernel: btrfs: relocating block group 1723913469952 > >> flags 9 > >> After that the machine becomes immediately unresponsive. > >> > >> As I did not see anything that might be related to my problem in the > >> changelog for 2.6.35.1 I did not try again with this version. > >> > >> > > Do you have more than one machines? would you please setup netconsole > > to see what happen. > > > I have reproduced the error on v2.6.35.1 and recorded all kernel output > with netconsole. The interesting point is that this time the machine did > not crash but the btrfs balance segfaulted at exact the same position > where the previous crashes had happened. Looks like another manifestation of the csum bug. Are you able to read all files from the affected volume? Did you tried a balance with an 2.6.34 kernel after the test with 2.6.35? 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.35.3] BUG: unable to handle kernel NULL pointer dereference at (null)
On Do 26.Aug'10 at 7:53:36 -0400, Chris Mason wrote: > On Thu, Aug 26, 2010 at 11:53:57AM +0200, Carlos R. Mafra wrote: > > Hi, > > > > I've just got this BUG: message in dmesg which I think is btrfs related. > > > > I have a btrfs filesystem in a memory card which I use to contain the > > cache and config of chromium (to avoid writing to much in the SSD): > > > > /dev/mmcblk0p1 on /home/mafra/mmc type btrfs > > (rw,noexec,nosuid,nodev,noatime,noacl,compress) > > > > and the last message before the bug is about the memory card. > > Hmmm it is definitely btrfs related. Do you continue to get it after > rebooting? No, after rebooting chromium refused to open (like it did during the BUG) but no BUG: message appeared. Then I deleted all chromium cache+config from the memory card and chromium worked again, but after suspending to RAM I noticed this: [ 6035.423238] PM: Syncing filesystems ... done. [ 6036.524889] Freezing user space processes ... [ 6056.533079] Freezing of tasks failed after 20.00 seconds (1 tasks refusing to freeze): [ 6056.533119] chromeD 0 7028 7015 0x0084 [ 6056.533124] 8800630a1c08 0086 00012d40 [ 6056.533129] 8800630a1fd8 8800630a1fd8 88006303e0c0 00012d40 [ 6056.533133] 00012d40 4000 4000 8800630a1fd8 [ 6056.533137] Call Trace: [ 6056.533145] [] ? ktime_get_ts+0xa9/0xe0 [ 6056.533150] [] ? sync_page_killable+0x0/0x40 [ 6056.533155] [] io_schedule+0x6e/0xb0 [ 6056.533158] [] sync_page+0x38/0x50 [ 6056.533161] [] sync_page_killable+0x9/0x40 [ 6056.533164] [] __wait_on_bit_lock+0x52/0xb0 [ 6056.533168] [] __lock_page_killable+0x62/0x70 [ 6056.533172] [] ? wake_bit_function+0x0/0x40 [ 6056.533175] [] ? find_get_page+0x19/0x90 [ 6056.533178] [] generic_file_aio_read+0x494/0x6d0 [ 6056.533183] [] do_sync_read+0xd2/0x110 [ 6056.533186] [] ? do_page_fault+0x186/0x390 [ 6056.533190] [] vfs_read+0xb3/0x160 [ 6056.533193] [] sys_read+0x4c/0x80 [ 6056.533197] [] system_call_fastpath+0x16/0x1b [ 6056.533207] [ 6056.533208] Restarting tasks ... done. but everything is working well AFAICT. -- 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.35.3] BUG: unable to handle kernel NULL pointer dereference at (null)
On Thu, Aug 26, 2010 at 11:53:57AM +0200, Carlos R. Mafra wrote: > Hi, > > I've just got this BUG: message in dmesg which I think is btrfs related. > > I have a btrfs filesystem in a memory card which I use to contain the > cache and config of chromium (to avoid writing to much in the SSD): > > /dev/mmcblk0p1 on /home/mafra/mmc type btrfs > (rw,noexec,nosuid,nodev,noatime,noacl,compress) > > and the last message before the bug is about the memory card. Hmmm it is definitely btrfs related. Do you continue to get it after rebooting? -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: Poor creat/delete files performance
On Wed, 18 Aug 2010 20:57:43 -0400, Chris Mason wrote: Since the files are empty, and we aren't doing enough files to trigger IO, it is really benchmarking the cost of the btree insertions/removals in comparison with ext4. I do expect this to be higher because btrfs is indexing the directories twice (once by name and once by sequence number for faster backups). On my machine: Btrfs defaults: Create files: Total files: 5 Total time: 0.916680 Average time: 0.18 Delete files: Total files: 5 Total time: 1.329892 Average time: 0.27 Ext4: creat_unlink 5 Create files: Total files: 5 Total time: 0.718190 Average time: 0.14 Delete files: Total files: 5 Total time: 0.308815 Average time: 0.06 We're definitely slower than ext4, but as Ric's benchmarks show things tend to tilt in our favor once IO is actually done. There are two big things that would help fix this performance gap: Switching the extent buffer rbtree into a radix tree (esp a lockless radix tree), and delaying insertion of the inode so that we can do more in btree operations in bulk. The radix tree is a much easier and more contained project. The type of the radix tree's key is "unsigned long", but the type of the extent buffer's key is "u64". That is we can't use the radix tree instead of rbtree on the 32-bits boxs. So we can't switching the extent buffer rbtree into a radix tree. Thanks Miao Xie -- 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
[2.6.35.3] BUG: unable to handle kernel NULL pointer dereference at (null)
Hi, I've just got this BUG: message in dmesg which I think is btrfs related. I have a btrfs filesystem in a memory card which I use to contain the cache and config of chromium (to avoid writing to much in the SSD): /dev/mmcblk0p1 on /home/mafra/mmc type btrfs (rw,noexec,nosuid,nodev,noatime,noacl,compress) and the last message before the bug is about the memory card. [ 148.149179] mmcblk0: retrying using single block read [ 148.152014] BUG: unable to handle kernel NULL pointer dereference at (null) [ 148.152021] IP: [] extent_range_uptodate+0x51/0xa0 [ 148.152030] PGD 72c37067 PUD 7d64b067 PMD 0 [ 148.152035] Oops: [#1] SMP [ 148.152038] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq [ 148.152041] CPU 1 [ 148.152043] Modules linked in: snd_seq snd_seq_device snd_hda_codec_idt i2c_i801 snd_hda_intel snd_hda_codec sky2 uvcvideo iwlagn snd_hwdep evdev [ 148.152053] [ 148.152057] Pid: 2731, comm: btrfs-endio-met Not tainted 2.6.35.3+ #12 VAIO/VGN-FZ240E [ 148.152059] RIP: 0010:[] [] extent_range_uptodate+0x51/0xa0 [ 148.152064] RSP: 0018:880079acddd0 EFLAGS: 00010246 [ 148.152066] RAX: RBX: 43eba000 RCX: [ 148.152068] RDX: 0001 RSI: 00043eba RDI: 0001 [ 148.152071] RBP: 880079acddf0 R08: R09: [ 148.152073] R10: 1000 R11: R12: 88007b40eb18 [ 148.152076] R13: 43ebadff R14: 880079ab R15: 880079acde80 [ 148.152079] FS: () GS:880001b0() knlGS: [ 148.152081] CS: 0010 DS: ES: CR0: 8005003b [ 148.152084] CR2: CR3: 70be9000 CR4: 06e0 [ 148.152086] DR0: DR1: DR2: [ 148.152088] DR3: DR6: 0ff0 DR7: 0400 [ 148.152091] Process btrfs-endio-met (pid: 2731, threadinfo 880079acc000, task 880079aca8c0) [ 148.152093] Stack: [ 148.152094] 8104e730 880069b9c8f8 88007e87ca40 880069b9c8c0 [ 148.152098] <0> 880079acde20 8118a42d 88007bbc70c0 880069b9c8f8 [ 148.152102] <0> 88007bbc70d8 88007bbc7110 880079acdee0 811b98f0 [ 148.152107] Call Trace: [ 148.152113] [] ? process_timeout+0x0/0x10 [ 148.152118] [] end_workqueue_fn+0x10d/0x130 [ 148.152122] [] worker_loop+0xb0/0x5a0 [ 148.152126] [] ? worker_loop+0x0/0x5a0 [ 148.152130] [] kthread+0x8e/0xa0 [ 148.152135] [] kernel_thread_helper+0x4/0x10 [ 148.152138] [] ? kthread+0x0/0xa0 [ 148.152142] [] ? kernel_thread_helper+0x0/0x10 [ 148.152144] Code: d3 ff ff 89 c2 b8 01 00 00 00 85 d2 75 56 4c 39 eb 77 51 0f 1f 80 00 00 00 00 48 89 de 49 8b 7c 24 10 48 c1 ee 0c e8 3f 21 ef ff 00 08 74 2a 48 89 c7 48 81 c3 00 10 00 00 e8 4b af ef ff 49 [ 148.152176] RIP [] extent_range_uptodate+0x51/0xa0 [ 148.152180] RSP [ 148.152182] CR2: [ 148.152185] ---[ end trace c11a5009b12451d7 ]--- Full dmesg is here http://www.aei.mpg.de/~crmafra/dmesg-2.6.35.3.txt Is there something else I should provide to help debug this? -- 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
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
The "The status of btrfsck" thread
Hi, I'm aware that btrfs doesn't have a functioning fsck tool that fixes errors. I was just wondering (I'm sure many are, also) if there is a working btrfsck somewhere in the pipeline. If there is some sort of rough estimate to when it'll be available, please state it here. If you're not confident about any release date, it's no big deal. I just want an organized place to sift through things regarding btrfsck (since it's pretty crucial) -- 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: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
On Wed, 2010-08-25 at 20:09 -0700, David Rientjes wrote: > > Oh, we can determine an upper bound. You might just not like it. > > Actually ext3/ext4 shouldn't be as bad as XFS, which Dave estimated to > > be around 400k for a transaction. My guess is that the worst case for > > ext3/ext4 is probably around 256k or so; like XFS, most of the time, > > it would be a lot less. (At least, if data != journalled; if we are > > doing data journalling and every single data block begins with > > 0xc03b3998U, we'll need to allocate a 4k page for every single data > > block written.) We could dynamically calculate an upper bound if we > > had to. Of course, if ext3/ext4 is attached to a network block > > device, then it could get a lot worse than 256k, of course. > > > On my 8GB machine, /proc/zoneinfo says the min watermark for ZONE_NORMAL > is 5086 pages, or ~20MB. GFP_ATOMIC would allow access to ~12MB of that, > so perhaps we should consider this is an acceptable abuse of GFP_ATOMIC as > a fallback behavior when GFP_NOFS or GFP_NOIO fails? Agreed with the fact that 400k isn't much to worry about. Not agreed with the GFP_ATOMIC stmt. Direct reclaim already has PF_MEMALLOC, but then we also need a concurrency limit on that, otherwise you can still easily blow though your reserves by having 100 concurrency users of it, resulting in an upper bound of 4k instead, which will be too much. There were patches to limit the direct reclaim contexts, not sure they ever got anywhere.. It is something to consider in the re-design of the whole direct-reclaim/writeback paths though.. -- 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: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
On Wed, Aug 25, 2010 at 08:09:21PM -0700, David Rientjes wrote: > On Wed, 25 Aug 2010, Ted Ts'o wrote: > > > I think it's really sad that the caller can't know what the upper bounds > > > of its memory requirement are ahead of time or at least be able to > > > implement a memory freeing function when kmalloc() returns NULL. > > > > Oh, we can determine an upper bound. You might just not like it. > > Actually ext3/ext4 shouldn't be as bad as XFS, which Dave estimated to > > be around 400k for a transaction. My guess is that the worst case for > > ext3/ext4 is probably around 256k or so; like XFS, most of the time, > > it would be a lot less. (At least, if data != journalled; if we are > > doing data journalling and every single data block begins with > > 0xc03b3998U, we'll need to allocate a 4k page for every single data > > block written.) We could dynamically calculate an upper bound if we > > had to. Of course, if ext3/ext4 is attached to a network block > > device, then it could get a lot worse than 256k, of course. > > > > On my 8GB machine, /proc/zoneinfo says the min watermark for ZONE_NORMAL > is 5086 pages, or ~20MB. GFP_ATOMIC would allow access to ~12MB of that, > so perhaps we should consider this is an acceptable abuse of GFP_ATOMIC as > a fallback behavior when GFP_NOFS or GFP_NOIO fails? It would take a handful of concurrent transactions in XFS with worst case memory allocation requirements to exhaust that pool, and then we really would be in trouble. Alternatively, it would take a few allocations from each of a couple of thousand concurrent transactions to get to the same point. Bound memory pools only work when serialised access to the pool can be enforced and there are no dependencies on other operations in progress for completion of the work and freeing of the memory. This is where it becomes exceedingly difficult to guarantee progress. One of the ideas that has floated around (I think Mel Gorman came up with it first) was that if hardening the filesystem is so difficult, why not just harden a single path via a single thread? e.g. we allow the bdi flusher thread to have a separate reserve pool of free pages, and when memory allocations start to fail, then that thread can dip into it's pool to complete the writeback of the dirty pages being flushed. When a fileystem attaches to a bdi, it can specify the size of the reserve pool it needs. This can be easily tested for during allocation (say a PF_ flag) and switched to the reserve pool as necessary. because it is per-thread, access to the pool is guaranteed to serialised. Memory reclaim can then refill these pools before putting pages on freelists. This could give us a mechanism for ensuring that allocations succeed in the ->writepage path without needing to care about filesystem implementation details. And in the case of ext3/4, a pool could be attached to the jbd thread as well so that it never starves of memory when commits are required... So, rather than turning filesystems upside down, maybe we should revisit per-thread reserve pools for threads that are tasked with cleaning pages for the VM? Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- 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
