headers
Daniel Phillips | 1 May 05:49

Re: Current Activities?

On Wednesday 29 April 2009, t3right.thebashar <at> xoxy.net wrote:
> Hi Daniel,
> 
> I want to apologize upfront if I sound like one of those "when will it
> be done" questions that are best left unasked with most open source
> projects.  Actually, I'm just really curious about what's been going
> on lately.  I am somewhat embarrassed to admit that I became
> fascinated with tux3's development since the first time it was
> featured in an article on kerneltrap.  I've greatly enjoyed reading
> your design notes and dialog with the btrfs team.  I had no naive
> hopes that tux3 would get integrated into the linux kernel
> immediately, but I've been extremely surprised at the loss of public
> progress notes from you after the initial review request back and
> forth died off.  In fact it seems like there's only been 7 postings
> from you in the month since the last kernel merge related thread.
> 
> I've really missed the public view into tux3's progress.  If it's not
> too presumptuous, how are you? How's tux3 coming along?  What part of
> the kernel port is taking the bulk of the work?  What new and
> interesting challenges have you been wrestling with?

Actually, I have been busy with real life for the last couple
of months.  An interesting challenge is how I can keep up the
previous development without any corporate support.  Zero.  Zip.
Nada.  There has been exactly zero support from the usual
suspects, who all have their own good reasons no doubt, which
do not necessarily have much to do with the good of the Linux
kernel or the Linux community.

That challenge is being addressed.  Addressing it takes time and
(Continue reading)

Permalink | Reply | 19 comments |
headers
OGAWA Hirofumi | 5 May 00:01
Picon
Gravatar

current my atomic-commit prototype

Hi,

This is for sharing the my current state to yours. It implements the
more codes for atomic-commit, not completed though.

My current issue is to retire the log block, it is a bit complex part to
think about it. Maybe, it has the different defree state compared to
normal one. (I'm not sure yet).

Well, anyway, the patchset is

	http://userweb.kernel.org/~hirofumi/atomic.tar.gz

The part of issue would be the following patches mainly.

	commit-log-new-cycle.patch
        commit-log-defree-fixes.patch

Thanks.
--

-- 
OGAWA Hirofumi <hirofumi <at> mail.parknet.co.jp>
Permalink | Reply | 4 comments |
headers
OGAWA Hirofumi | 5 May 14:56
Picon
Gravatar

Re: current my atomic-commit prototype

OGAWA Hirofumi <hirofumi <at> mail.parknet.co.jp> writes:

> This is for sharing the my current state to yours. It implements the
> more codes for atomic-commit, not completed though.
>
> My current issue is to retire the log block, it is a bit complex part to
> think about it. Maybe, it has the different defree state compared to
> normal one. (I'm not sure yet).
>
> Well, anyway, the patchset is
>
> 	http://userweb.kernel.org/~hirofumi/atomic.tar.gz
>
> The part of issue would be the following patches mainly.
>
> 	commit-log-new-cycle.patch
>         commit-log-defree-fixes.patch

I've thought about the issue of freeing the log blocks.  And I wrote the
figure for it.

     http://userweb.kernel.org/~hirofumi/note.defree-logs

This is based on bfree log of log blocks from flips, and I hope this
solves the issue, and helps to think about it at least.  If there is any
suggestion or something, please let me know.

Thanks.
--

-- 
OGAWA Hirofumi <hirofumi <at> mail.parknet.co.jp>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Martin Steigerwald | 5 May 20:49
Picon

Re: current my atomic-commit prototype

Am Dienstag 05 Mai 2009 schrieb OGAWA Hirofumi:
> OGAWA Hirofumi <hirofumi <at> mail.parknet.co.jp> writes:
> > This is for sharing the my current state to yours. It implements the
> > more codes for atomic-commit, not completed though.
> >
> > My current issue is to retire the log block, it is a bit complex part
> > to think about it. Maybe, it has the different defree state compared
> > to normal one. (I'm not sure yet).
> >
> > Well, anyway, the patchset is
> >
> > 	http://userweb.kernel.org/~hirofumi/atomic.tar.gz
> >
> > The part of issue would be the following patches mainly.
> >
> > 	commit-log-new-cycle.patch
> >         commit-log-defree-fixes.patch
>
> I've thought about the issue of freeing the log blocks.  And I wrote
> the figure for it.
>
>      http://userweb.kernel.org/~hirofumi/note.defree-logs

Hmmm, the URL can't be found on the server. Thats at least what Icedove 
and Konqueror report here.

(I think I likely could not comment on it, cause I lack the deeper 
understanding of how Tux3 work, but others might be able too)

--

--
(Continue reading)

Permalink | Reply | 2 comments |
headers
Philip Pokorny | 5 May 22:46
Favicon

current my atomic-commit prototype

The correct URL is:
http://userweb.kernel.org/~hirofumi/notes/note.defree-logs

But it might be better if they were renamed with a ".txt" extension so 
the web server will attach the correct mime type to the file instead of 
"binary"

Phil P.

--

-- 
Philip Pokorny, RHCE, Chief Arch. & Sr. Dir. HW & Field Eng.
Tel: 415-954-2823   Cell: 415-370-0835
Fax: 415-954-2899   Toll Free: 888-PENGUIN
PENGUIN COMPUTING, INC.
www.penguincomputing.com
Permalink | Reply | 0 comments |
headers
Samuel Harrington | 6 May 01:54
Picon

Re: current my atomic-commit prototype

On Tue, May 5, 2009 at 12:49 PM, Martin Steigerwald <Martin <at> lichtvoll.de> wrote:
>
> Am Dienstag 05 Mai 2009 schrieb OGAWA Hirofumi:
> >      http://userweb.kernel.org/~hirofumi/note.defree-logs
>
> Hmmm, the URL can't be found on the server. Thats at least what Icedove
> and Konqueror report here.

Try
http://userweb.kernel.org/~hirofumi/notes/note.defree-logs
instead.

- Samuel Harrington
Permalink | Reply | 1 comment |
headers
OGAWA Hirofumi | 6 May 02:35
Picon
Gravatar

Re: current my atomic-commit prototype

Samuel Harrington <robotsam <at> gmail.com> writes:

> On Tue, May 5, 2009 at 12:49 PM, Martin Steigerwald <Martin <at> lichtvoll.de> wrote:
>>
>> Am Dienstag 05 Mai 2009 schrieb OGAWA Hirofumi:
>> >      http://userweb.kernel.org/~hirofumi/note.defree-logs
>>
>> Hmmm, the URL can't be found on the server. Thats at least what Icedove
>> and Konqueror report here.
>
> Try
> http://userweb.kernel.org/~hirofumi/notes/note.defree-logs
> instead.

Whoops, sorry for that.

> The correct URL is:
> http://userweb.kernel.org/~hirofumi/notes/note.defree-logs
> 
> But it might be better if they were renamed with a ".txt" extension so 
> the web server will attach the correct mime type to the file instead of 
> "binary"

I see, I was forgetting about it. Well, basically, it was intended the
private use for myself.

It was my laziness. I'll try to post more carefully, and try to write
the better note. :)

Thanks.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Goran Mekić | 10 May 11:00

Re: Current Activities?

> Anyway, now would be a good time to have a discussion here on the Tux3
list about what can be done to get more helping hands
> involved in the heavy lifting.
    If that happens, I would be more then happy to give it a try. I'm Unix
admin at local company (read: have a lot of free time and at least one
spare machine for testing) behind god damn proxy, so I can't pull
repository to my machine. As a matter of fact, I'm vice president of my
town's LUG, so we could test it there (different machines (SPARC U60 and
U10 beside x86 - don't know if SPARC is supported), in company I've got
only Dell Optiplex machines), so it would be interesting
testing it there. Maybe some of better C programers would give it a try,
write a patch, or something. LUG's access to Internet is not
trough proxy, so I have no excuse for not trying it 'till now. :o) Anyway,
I would be more than glad to help if there would be any http access to
kernel three with tux3 patches applied (write doc, for
example). Hope it will get to -mm soon. Anyway, I've got little time when
not in company (moving to new flat), but I'll give it a try as soon as
posible. It was about time I start learing kernel programming. :o) C ya!

PS. Sorry, Daniel, didn't realize I was replying to you only.

--

-- 
FreeB(eer)S(ex)D(rugs) are the real daemons
Permalink | Reply | 0 comments |
headers
OGAWA Hirofumi | 14 May 08:39
Picon
Gravatar

current my atomic-commit prototype (v2)

Hi,

This is for sharing the my current state to yours again.

I think the retiring the log block are almost done. However, it is a bit
complex part, so we might have to revisit to it.

I'm trying to implement the atomic-commit on create() path. Well, so, we
will need to implement the replay code to test those soon.

BTW, maybe, I found the bug of insert_leaf(). The cursor should have the
corrent path to leaf, however, after insert_leaf(), it may not have the
corrent path. Because, it sets the bnode of splited to cursor, but the
splited bnode may not be the path to leaf.

Well, anyway, the patchset is

	http://userweb.kernel.org/~hirofumi/atomic.tar.gz

and notes are

	http://userweb.kernel.org/~hirofumi/notes/

The note_flush-create.txt is the note of path which I'm implementing

Sorry, however, I'd like to still use tarball for now. Because, I'm
usually re-modify the patches to get/make good diff/code.
Make (temporary) first version, review it, rethink it, modify and refactor.
This is good way for me to manage the codes until some sort of completion.
SCM management for this work just bother me.
(Continue reading)

Permalink | Reply | 2 comments |
headers
OGAWA Hirofumi | 15 May 18:29
Picon
Gravatar

Re: current my atomic-commit prototype (v2)

OGAWA Hirofumi <hirofumi <at> mail.parknet.co.jp> writes:

> BTW, maybe, I found the bug of insert_leaf(). The cursor should have the
> corrent path to leaf, however, after insert_leaf(), it may not have the
> corrent path. Because, it sets the bnode of splited to cursor, but the
> splited bnode may not be the path to leaf.

OK, I think I've found the bug of insert_leaf(). Current code updates
the childblock/childkey to the splited new block blindly. It means this
is assuming the splited new block has inserting leaf.

But, it is not true. So, this patch fixes the cursor position only if
splited new block has target child.

Maybe, I'll make the bug-fix patchset like this, and post.

Thanks.

diff -puN user/kernel/btree.c~insert_leaf-cursor-path-fix user/kernel/btree.c
--- tux3/user/kernel/btree.c~insert_leaf-cursor-path-fix	2009-05-16 00:30:58.000000000 +0900
+++ tux3-hirofumi/user/kernel/btree.c	2009-05-16 01:19:06.000000000 +0900
@@ -649,7 +649,8 @@ static int insert_leaf(struct cursor *cu
 		parent->count = to_be_u32(half);

 		/* if the cursor is in the new node, use that as the parent */
-		if (at->next > parent->entries + half) {
+		int child_is_left = at->next <= parent->entries + half;
+		if (!child_is_left) {
 			struct index_entry *newnext;
 			mark_buffer_dirty(parentbuf);
(Continue reading)

Permalink | Reply | 1 comment |

Gmane