Tux 3 developement seems to have been on ice, is there anything that could be done to get it going again ? If one was to start looking at some part whats most important ? tolls/kernel integration/fs itself ? / regards, Lars Segerlund.
Hi,
I am trying to port TUX3 onto the ARM9 environment. Since this is the first time I am working on a file-system, I am trying to first mount the TUX3 on my linux machine.
I have followed the instructions given in this link: http://lkml.indiana.edu/hypermail/linux/kernel/0812.3/01600.html
But, I get stuck in this line: mount /dev/<testpartition> /mnt. The machine hangs when I try to mount the TUX3 onto an external-pen-drive that I have mapped as /dev/sdb1/
The dmesg info taken after hard-rebooting my machine is:
..........
... sdb: sdb1
... sd 2:0:0:0: [sdb] Attached SCSI removable disk <<<after this the machine hangs>>>
..........
The mkfs command works fine before I try to mount, since I could find "tux3" listed under the "/proc/filesystems", though it does not say "nodev" against it. (i am not sure if this "nodev" not showing up is critical observation)
It will be great if anyone can help me in mounting TUX3 onto the linux machine.
TIA.
Warm Regards,
Balkrishnan
_______________________________________________ Tux3 mailing list Tux3 <at> tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3
hello sir.....
myself Nandan, i had completed my engineering in Computer Science. sir i am beginner to filesystem. i want to understand tux3 filesystem pl help me.
i want to understand the source. from where should i begin to trace the code pl help me sir.........
_______________________________________________ Tux3 mailing list Tux3 <at> tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3
Greetings, I have zero knowledge as far as filesystems are concerned but I'm interested in learning what Tux3 is and how it works. I started digging into the Tux3 mailing list but, truth is, that I couldn't follow most of the threads. I also tried reading related articles like: http://lwn.net/Articles/288896/ http://tux3.org/shapor-tux3/doc/design.html but I didn't get far either. Apart from basic and unrelated stuff (like how B-trees work, etc.), can you propose me some basic reading on filesystem design so that I can, at least, follow some basic discussion on the mailing list and start checking out the code? As a matter of fact, I think that publishing such a list on the tux3.org would motivate many interested developers on 'joining' the project. Thanks :)
Hi,
Those patches fixes the recent broken things by atomic commit. I hope
this patchset fixes all of those.
- add tux_new_logmap() to create proper logmap (please review and check)
- create ->logmap for some places
- use defer btree root allocation for itable (with FIXME)
And also this cleans inode stuff up, and as usual, is including various
small bugfixes.
static-http://userweb.kernel.org/~hirofumi/tux3/
Please review, and pull if ok.
Thanks.
--
--
OGAWA Hirofumi <hirofumi <at> mail.parknet.co.jp>
Sir,
We are a group of 4 under graduate students who wish to
complete a project in kvm.We have gone through your to-do lists but we
did not find anything that we could do in a whole year.Can you please
suggest something that might be possible for us to implement?
Thanking you,
Regards,
--
Shweta Shetty
Parul Nalavade
Aruna Medhekar
Ruta Gadkari
_______________________________________________ Tux3 mailing list Tux3 <at> tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3
Suppress idiotic gcc warning for constant shift on 32 bit arch
1--- a/user/utility.h Mon Jun 29 09:55:28 2009 +0900
2+++ b/user/utility.h Mon Jun 29 10:10:21 2009 -0700
3@@ -19,11 +19,10 @@ static __always_inline unsigned long __f
4 {
5 int num = 0;
6
7- if (BITS_PER_LONG == 64) {
8- if ((word & 0xffffffff) == 0) {
9- num += 32;
10- word >>= 32;
11- }
12+ if (BITS_PER_LONG == 64 && !(word & 0xffffffff)) {
13+ num += 32;
14+ word >>= 16; /* work around idiotic gcc warning */
15+ word >>= 16; /* work around idiotic gcc warning */
16 }
17 if ((word & 0xffff) == 0) {
18 num += 16;
As BITS_PER_LONG is a macro, wouldn't it make more scene to include
that as a preprocess directive to get rid of the compiler warning?
Michael Pattrick
http://www.rhinovirus.org/math
Hello I am creating a birthday calendar for myself. Can you please click on the link below and enter your birthday for me? http://www.birthdayalarm.com/bd2/85334167a876025448b1472437903c808070343d1386 Nandan
Hi, Those patches are start to logging for atomic commit, and fix the stage_delta()/flush_log() to flush correctly. Also, this fixes the deferred bfree stuff. And some bug fixes. The problem of this patchset is, first of all, I worked only for creation path as start. I copied code from kernel to utility.*, so we would need to think about license of those, or remove the code from this patch. And test is not enough, some programs/code-path would be untested at all. Main known problems are: It will still use writeback stuff, so, we need more code to switch to commit stuff. But, before switch, we will need to add to flush bitmap inode. And This is first one to start logging, so, there may be bugs on around those. Kernel is compile test only. And this may change the disk format without changing revision. Well, there would be many problems. But, it starts the atomic-commit more or less. static-http://userweb.kernel.org/~hirofumi/tux3/ Please review, and pull if ok. Thanks. -- -- OGAWA Hirofumi <hirofumi <at> mail.parknet.co.jp>
Hi, Those patches are bug fixes in xattr.c and writeback.c. And those add the deferred ileaf update for inode number allocation. It defers the ileaf update (this is only for inum allocation) until backend for atomic-commit. To do it, this allows the inode doesn't have the data btree, and at the first write, allocate btree. static-http://userweb.kernel.org/~hirofumi/tux3/ Please review, and pull if ok. Thanks. -- -- OGAWA Hirofumi <hirofumi <at> mail.parknet.co.jp>
Hi, Those patches add the inode dirty management and reference count. I think those can be used for both of good writeback flush and atomic-commit. I guess the issues of this patchset are, iget() is not finding the all in-core inode (reopen is not allowed, it's same with current though). And tux3fuse patches are almost untested, sorry. static-http://userweb.kernel.org/~hirofumi/tux3/ Please review, and pull if ok. Thanks. -- -- OGAWA Hirofumi <hirofumi <at> mail.parknet.co.jp>
 |
|
|
|
|
|
|
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
RSS Feed1 | |
|---|---|
2 | |
1 | |
17 | |
3 | |
4 | |
16 | |
9 | |
86 | |
50 | |
145 | |
176 | |
78 | |
67 | |
139 | |
68 | |
19 |