Re: Please help me to contribute to btrfs project
Ajesh js coolajes...@gmail.com writes: Hi, I have used the btrfs filesystem in one of my projects and I have added a small feature to it. I feel that the same feature will be useful for others too. Hence I would like to contribute the same to open source. Excellent! If everything works fine and this feature is not already added by somebody else, this will be my first contribution to the opensource I am excited to join the huge family of opensource :) Please help me with a precise steps to do the same. In general the way to contribute is to send a patch for review. You should have a look at the code style guidelines[1] and patch submission guidelines[2] in the kernel tree. For nontrivial changes the patch should be accompanied by a cover letter describing the change and the motivations for any non-obvious design decisions. It is possible that your change is acceptable as-is. More likely, however, is that there will be some discussion and requests for changes. Eventually the review process will produce a merge-worthy patch. The first step, however, is sending something concrete for community review. Cheers, - Ben [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/CodingStyle [2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches pgp9hFdMVn2wY.pgp Description: PGP signature
Re: btrfs frozen solid with postgresql dbs
On Sat, 16 Apr 2011 15:07:50 +0200, krz...@gmail.com krz...@gmail.com wrote: kernel: 2.6.37.6 At least twice I've experienced problems when using btrfs with ssd for postgresql db storage. Server gets frozen, i even can't kill it using kill -9, I cant chown postgresql db dir (it never gets done). If I initiate copy operation of postgresql db dir to another partition (without actually switching to using it) everything starts to work fine for some time... You may want to try Sysrq-W to see where the server is stuck. Just a thought... - Ben -- 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: Recovering data from disk with loose cable
On Wed, 9 Feb 2011 21:46:38 -0500, Ben Gamari bgam...@gmail.com wrote: We have a disk array behind two external SATA port multipliers (four disks on each multiplier) which has been running btrfs (RAID 1 for both data and metadata). Unfortunately, earlier today it seems one of the SATA cables came loose, resulting in the kernel (2.6.37) eventually OOPSing although apparently not before writing quite a bit of data. Upon reboot, I was met with the dreaded, disk-io.c:741: open_ctree_fd: Assertion `!(!tree_root-node)' failed. Unfortunately any attempt to run any of the btrfs-progs utilities (from git) met a similar end. There was recently a patch to try harder in recovering from this problem posted to the list[1], although unfortunately it is unable to find a root. Considering there are eight disks in the array and only four were affected by the loose cable, I find it very hard to believe there is no way to recover this volume. Any suggestions at all would be greatly appreciated. Recovering this data would mean a lot. Thanks, Given there has been no response to this, I suppose I should assume this data is unrecoverable? It's not the end of the world if so, but again, it would be nice to get a few files and it seems like a small subset of the metadata is corrupted. Cheers, - Ben -- 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: New btrfsck status
On Thu, 10 Feb 2011 07:17:10 -0500, Chris Mason chris.ma...@oracle.com wrote: Excerpts from Ben Gamari's message of 2011-02-09 21:52:20 -0500: Is there a timeline for getting btrfsck into some sort of usable form? Yes, but its still real soon now. I've been at about 90% done since Christmas. It would have been out last week but I've been chasing a debugging a very difficult corruption under load. I finally found a race in btrfs causing the corruption and now I'm back on fsck full time again. Glad to hear this. Thank you very much for your update. With respect to the other thread (re: loose eSATA cable). I can keep the array around in its current form if it would provide a good test case for btrfsck. That being said, I'm really looking to recover some of the data from this array if at all possible. Cheers, - Ben -- 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
Recovering data from disk with loose cable
We have a disk array behind two external SATA port multipliers (four disks on each multiplier) which has been running btrfs (RAID 1 for both data and metadata). Unfortunately, earlier today it seems one of the SATA cables came loose, resulting in the kernel (2.6.37) eventually OOPSing although apparently not before writing quite a bit of data. Upon reboot, I was met with the dreaded, disk-io.c:741: open_ctree_fd: Assertion `!(!tree_root-node)' failed. Unfortunately any attempt to run any of the btrfs-progs utilities (from git) met a similar end. There was recently a patch to try harder in recovering from this problem posted to the list[1], although unfortunately it is unable to find a root. Considering there are eight disks in the array and only four were affected by the loose cable, I find it very hard to believe there is no way to recover this volume. Any suggestions at all would be greatly appreciated. Recovering this data would mean a lot. Thanks, - Ben [1] https://patchwork.kernel.org/patch/506631/ [2] Output from patched btrfsck $ sudo ./btrfsck /dev/sdj trying potential super #0 at bytenr 65536 super #0 at bytenr 65536 has better generation 43887 than 0, using that trying potential super #1 at bytenr 67108864 super #1 at bytenr 67108864 has same generation 43887 than 43887, skipping warning: super #1 at bytenr 67108864 has different contents! trying potential super #2 at bytenr 274877906944 super #2 at bytenr 274877906944 has same generation 43887 than 43887, skipping warning: super #2 at bytenr 274877906944 has different contents! trying potential super #0 at bytenr 65536 super #0 at bytenr 65536 has better generation 43887 than 0, using that trying potential super #1 at bytenr 67108864 super #1 at bytenr 67108864 has same generation 43887 than 43887, skipping warning: super #1 at bytenr 67108864 has different contents! trying potential super #2 at bytenr 274877906944 super #2 at bytenr 274877906944 has same generation 43887 than 43887, skipping warning: super #2 at bytenr 274877906944 has different contents! trying potential super #0 at bytenr 65536 super #0 at bytenr 65536 has better generation 43887 than 0, using that trying potential super #1 at bytenr 67108864 super #1 at bytenr 67108864 has same generation 43887 than 43887, skipping warning: super #1 at bytenr 67108864 has different contents! trying potential super #2 at bytenr 274877906944 super #2 at bytenr 274877906944 has same generation 43887 than 43887, skipping warning: super #2 at bytenr 274877906944 has different contents! trying potential super #0 at bytenr 65536 super #0 at bytenr 65536 has better generation 43887 than 0, using that trying potential super #1 at bytenr 67108864 super #1 at bytenr 67108864 has same generation 43887 than 43887, skipping warning: super #1 at bytenr 67108864 has different contents! trying potential super #2 at bytenr 274877906944 super #2 at bytenr 274877906944 has same generation 43887 than 43887, skipping warning: super #2 at bytenr 274877906944 has different contents! trying potential super #0 at bytenr 65536 super #0 at bytenr 65536 has better generation 43887 than 0, using that trying potential super #1 at bytenr 67108864 super #1 at bytenr 67108864 has same generation 43887 than 43887, skipping warning: super #1 at bytenr 67108864 has different contents! trying potential super #2 at bytenr 274877906944 super #2 at bytenr 274877906944 has same generation 43887 than 43887, skipping warning: super #2 at bytenr 274877906944 has different contents! trying potential super #0 at bytenr 65536 super #0 at bytenr 65536 has better generation 43884 than 0, using that trying potential super #1 at bytenr 67108864 super #1 at bytenr 67108864 has same generation 43884 than 43884, skipping warning: super #1 at bytenr 67108864 has different contents! trying potential super #2 at bytenr 274877906944 super #2 at bytenr 274877906944 has same generation 43884 than 43884, skipping warning: super #2 at bytenr 274877906944 has different contents! trying potential super #0 at bytenr 65536 super #0 at bytenr 65536 has better generation 43884 than 0, using that trying potential super #1 at bytenr 67108864 super #1 at bytenr 67108864 has same generation 43884 than 43884, skipping warning: super #1 at bytenr 67108864 has different contents! trying potential super #2 at bytenr 274877906944 super #2 at bytenr 274877906944 has same generation 43884 than 43884, skipping warning: super #2 at bytenr 274877906944 has different contents! trying potential super #0 at bytenr 65536 super #0 at bytenr 65536 has better generation 43884 than 0, using that trying potential super #1 at bytenr 67108864 super #1 at bytenr 67108864 has same generation 43884 than 43884, skipping warning: super #1 at bytenr 67108864 has different contents! trying potential super #2 at bytenr 274877906944 super #2 at bytenr 274877906944 has same generation 43884 than 43884, skipping warning: super #2 at
New btrfsck status
Hey all, Over the last several months there have been many claims regarding the release of the rewritten btrfsck. Unfortunately, despite numerous claims that it will be released Real Soon Now(c), I have yet to see even a repository with preliminary code. Did I miss an announcement? There is something to be said for release early, release often. Is there a timeline for getting btrfsck into some sort of usable form? Cheers, - Ben -- 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
[PATCH] Improve error handling in filesystem df
The return values of ioctl weren't being printed to stderr on failure,
causing the command to silently fail, resulting in a very confused
user.
Signed-off-by: Ben Gamari bgamari.f...@gmail.com
---
btrfs_cmds.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/btrfs_cmds.c b/btrfs_cmds.c
index 8031c58..45da2bd 100644
--- a/btrfs_cmds.c
+++ b/btrfs_cmds.c
@@ -857,6 +857,7 @@ int do_df_filesystem(int nargs, char **argv)
ret = ioctl(fd, BTRFS_IOC_SPACE_INFO, sargs);
if (ret) {
+ fprintf(stderr, ERROR: can't query '%s' for free space
(%s)\n, path, strerror(-ret));
free(sargs);
return ret;
}
@@ -875,6 +876,7 @@ int do_df_filesystem(int nargs, char **argv)
ret = ioctl(fd, BTRFS_IOC_SPACE_INFO, sargs);
if (ret) {
+ fprintf(stderr, ERROR: can't query '%s' for free space
(%s)\n, path, strerror(-ret));
free(sargs);
return ret;
}
--
1.7.1
--
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 interactive performance with I/O loads with fsync()ing
On Sun, 11 Apr 2010 18:03:00 +0300, Avi Kivity a...@redhat.com wrote: On 04/09/2010 05:56 PM, Ben Gamari wrote: On Mon, 29 Mar 2010 00:08:58 +0200, Andi Kleena...@firstfloor.org wrote: Ben Gamaribgamari.f...@gmail.com writes: ext4/XFS/JFS/btrfs should be better in this regard I am using btrfs, so yes, I was expecting things to be better. Unfortunately, the improvement seems to be non-existent under high IO/fsync load. btrfs is known to perform poorly under fsync. Has the reason for this been identified? Judging from the nature of metadata loads, it would seem that it should be substantially easier to implement fsync() efficiently. - Ben -- 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
