headers
Jonas Fietz | 1 Dec 13:38
Picon
Favicon

Re: Developing Tux3 with UML - 64 Bit


Hi people,

as Daniel's root does not run with a 64Bit kernel, i created a new one.
It's only 23 MiB compressed. Feel free to improve upon it.

I also mirrored the original one; I hope you don't mind.

You can get the original from

	http://www.jonasfietz.de/tuxroot.tar.bz2

and the 64 bit version from

	 http://www.jonasfietz.de/tuxroot.amd64.tar.bz2

Hope it helps.

Greetings,

Jonas
Permalink | Reply | 1 comment |
headers
Daniel Phillips | 1 Dec 14:02

Re: Developing Tux3 with UML - 64 Bit

On Monday 01 December 2008 04:38, Jonas Fietz wrote:
> as Daniel's root does not run with a 64Bit kernel, i created a new one.
> It's only 23 MiB compressed. Feel free to improve upon it.

Thankyou very much!

> I also mirrored the original one; I hope you don't mind.

Not at all.  I uploaded yours here:

   http://tux3.org/downloads/tuxroot64.tar.bz2

and for consistency, there is now:

   http://tux3.org/downloads/tuxroot32.tar.bz2

Daniel
Permalink | Reply | 0 comments |
headers
OGAWA Hirofumi | 1 Dec 14:23
Picon
Gravatar

Re: cleanup and tux3graph improvement

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

> Those patches are trivial cleanup, and tux3graph improvement. Well, the
> output of tux3graph is not changed much, however, perhaps the
> preparation to dump the data which is pointed by extents is done almost.
>
> 	static-http://userweb.kernel.org/~hirofumi/tux3/
> 	http://userweb.kernel.org/~hirofumi/tux3-new.png

I've noticed "dot" (version 2.20.2) can create svg format. It's faster
than png, and can work on more bigger fs image.

    http://userweb.kernel.org/~hirofumi/tux3-big.svg.gz
--

-- 
OGAWA Hirofumi <hirofumi <at> mail.parknet.co.jp>
Permalink | Reply | 2 comments |
headers
Jonas Fietz | 1 Dec 19:56
Picon
Favicon

[PATCH 1/2] Implementing listattr for fuse: FIX unitialized sb->atomref_base and unatom_base


Hi,

maybe introduced through porting to the kernel, i believe these two
values were not initialized anymore. Thusly setting an xattr did not work.
I calculate them the same way as they are being calculated in
user/super.c. I hope this is correct; another method might be to save
them along with the sb.

Thanks to Hirofumi for helping me get there.

# HG changeset patch
# User Jonas Fietz <data <at> geekig.de>
# Date 1228156893 -3600
# Node ID 41fb4940acadb1cfd095bfeb68ea625b428dc1d6
# Parent  954112a5893e0da997d469a068b29108b07323b0
Fixed unitialized sb->atomref_base and sb->unatom_base

diff -r 954112a5893e -r 41fb4940acad user/kernel/super.c
--- a/user/kernel/super.c       Mon Dec 01 05:14:16 2008 +0900
+++ b/user/kernel/super.c       Mon Dec 01 19:41:33 2008 +0100
@@ -41,6 +41,8 @@
        sb->nextalloc = from_be_u64(super->nextalloc);
        sb->atomgen = from_be_u32(super->atomgen);
        sb->freeatom = from_be_u32(super->freeatom);
+       sb->atomref_base = 1 << (40 - sb->blockbits); // see xattr.c
+       sb->unatom_base = sb->unatom_base + (1 << (34 - sb->blockbits));

        return 0;
 }
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jonas Fietz | 1 Dec 20:18
Picon
Favicon

[PATCH 2/2] Implementing listattr for fuse: implementation of tux3_listxattr

Hi,

second part of my patch. As the note says, this is untested for multiple
xattrs.
Hirofumi and I just noticed another problem with the xattrs, so the last
patch may be faulty. So please don't apply that yet as further research
is needed.

# HG changeset patch
# User Jonas Fietz <data <at> geekig.de>
# Date 1228158752 -3600
# Node ID 746bbab5b39fc4755c316b368494e4031a67cecd
# Parent  41fb4940acadb1cfd095bfeb68ea625b428dc1d6
Implementation  of tux3_listxattr.
Quite simple, as it only has to patch through to xattr_list. This is still
untested for multiple xattrs as there are further problems with those

diff -r 41fb4940acad -r 746bbab5b39f user/tux3fuse.c
--- a/user/tux3fuse.c	Mon Dec 01 19:41:33 2008 +0100
+++ b/user/tux3fuse.c	Mon Dec 01 20:12:32 2008 +0100
@@ -613,8 +613,25 @@

 static void tux3_listxattr(fuse_req_t req, fuse_ino_t ino, size_t size)
 {
-	warn("not implemented");
-	fuse_reply_err(req, ENOSYS);
+	fprintf(stderr, "tux3_listxattr(%Lx, size:%u)\n", (L)ino, (unsigned
int)size);
+	
+	struct inode *inode = open_fuse_ino(ino);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Phillips | 1 Dec 21:19

Re: cleanup and tux3graph improvement

On Monday 01 December 2008 05:23, OGAWA Hirofumi wrote:
> OGAWA Hirofumi <hirofumi <at> mail.parknet.co.jp> writes:
> 
> > Those patches are trivial cleanup, and tux3graph improvement. Well, the
> > output of tux3graph is not changed much, however, perhaps the
> > preparation to dump the data which is pointed by extents is done almost.
> >
> > 	static-http://userweb.kernel.org/~hirofumi/tux3/
> > 	http://userweb.kernel.org/~hirofumi/tux3-new.png
> 
> I've noticed "dot" (version 2.20.2) can create svg format. It's faster
> than png, and can work on more bigger fs image.
> 
>     http://userweb.kernel.org/~hirofumi/tux3-big.svg.gz

I think we need that, judging from the trouble people had loading the
big png.  Can we make the svg support depend on the graphviz version?

Daniel
Permalink | Reply | 1 comment |
headers
OGAWA Hirofumi | 1 Dec 21:35
Picon
Gravatar

Re: cleanup and tux3graph improvement

Daniel Phillips <phillips <at> phunq.net> writes:

>> I've noticed "dot" (version 2.20.2) can create svg format. It's faster
>> than png, and can work on more bigger fs image.
>> 
>>     http://userweb.kernel.org/~hirofumi/tux3-big.svg.gz
>
> I think we need that, judging from the trouble people had loading the
> big png.  Can we make the svg support depend on the graphviz version?

Yes. However, graphviz seems to be already supporting svg at 2004.

	$ tux3graph [-v] volname
	$ dot -Tsvg volname.dot > foo.svg
	$ viewer foo.svg

We can use -Tsvg, instead of -Tpng.
--

-- 
OGAWA Hirofumi <hirofumi <at> mail.parknet.co.jp>
Permalink | Reply | 0 comments |
headers
Jonas Fietz | 1 Dec 21:46
Picon
Favicon

Re: Corrected: [PATCH 1/2] Implementing listattr for fuse: FIX unitialized sb->atomref_base and unatom_base


Hi,
Jonas Fietz wrote:
> user/super.c. I hope this is correct;
As one could have expected, it was not completely correct.
Here the updated patch

# HG changeset patch
# User Jonas Fietz <data <at> geekig.de>
# Date 1228164250 -3600
# Node ID 965fa90edabda66d20d01b628ee1a902de7951f1
# Parent  954112a5893e0da997d469a068b29108b07323b0
Fixed unitialized sb->atomref_base and sb->unatom_base and corrected
computation of unatom_base to not include the unitialized value of
itself but the value of atomref_base as an offset

diff --git a/user/kernel/super.c b/user/kernel/super.c
--- a/user/kernel/super.c
+++ b/user/kernel/super.c
@@ -41,6 +41,8 @@
 	sb->nextalloc = from_be_u64(super->nextalloc);
 	sb->atomgen = from_be_u32(super->atomgen);
 	sb->freeatom = from_be_u32(super->freeatom);
+	sb->atomref_base = 1 << (40 - sb->blockbits); // see xattr.c
+	sb->unatom_base = sb->atomref_base + (1 << (34 - sb->blockbits));

 	return 0;
 }
diff --git a/user/super.c b/user/super.c
--- a/user/super.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonas Fietz | 1 Dec 21:51
Picon
Favicon

PATCH: fix a small bug in filemap_extent_io

Spotted and fixed by hirofumi, i am just the messenger :)

# HG changeset patch
# User Jonas Fietz <data <at> geekig.de>
# Date 1228164310 -3600
# Node ID e6c5f679a1c0585cbe2d0e2b65ec51e0bd30d0b2
# Parent  965fa90edabda66d20d01b628ee1a902de7951f1
correct one case in filemap_extent_io, where the value of next_extend was not updated

diff --git a/user/kernel/filemap.c b/user/kernel/filemap.c
--- a/user/kernel/filemap.c
+++ b/user/kernel/filemap.c
@@ -90,7 +90,7 @@
 		limit = next_key(cursor, depth);
 	struct dleaf *leaf = bufdata(cursor[depth].buffer);
 	struct dwalk *walk = &(struct dwalk){ };
-dleaf_dump(&tux_inode(inode)->btree, leaf);
+	dleaf_dump(&tux_inode(inode)->btree, leaf);
 	/* Probe below io start to include overlapping extents */
 	dwalk_probe(leaf, sb->blocksize, walk, 0); // start at beginning of leaf just for now

@@ -125,6 +125,8 @@
 			if (start > dwalk_index(walk))
 				count -= start - dwalk_index(walk);
 			index += count;
+			next_extent = NULL;
+			continue;
 		}
 		block_t next_index = limit;
 		if ((next_extent = dwalk_next(walk))) {
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Phillips | 1 Dec 23:13

Re: PATCH: fix a small bug in filemap_extent_io

On Monday 01 December 2008 12:51, Jonas Fietz wrote:
> Spotted and fixed by hirofumi, i am just the messenger :)

Pulled your last three patches, thankyou!

Daniel
Permalink | Reply | 0 comments |

Gmane