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.(Continue reading)
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>
Hi, I've picked the bug-fix patches up from my patchset. And this changes is including the patch for packaging and reported bugs from Mario Fetka. Thanks Mario. static-http://userweb.kernel.org/~hirofumi/tux3/ Please review, and pull if ok. Thanks. -- -- OGAWA Hirofumi <hirofumi <at> mail.parknet.co.jp>
I like this a little more, to avoid depending on kernel headers for the
module compile. There should be no alignment issue, because super.magic
is ((packed)).
diff -r cb5655728089 user/kernel/super.c
--- a/user/kernel/super.c Fri Mar 27 16:12:32 2009 +0900
+++ b/user/kernel/super.c Sun May 17 15:52:59 2009 -0700
@@ -137,7 +137,6 @@ static int tux3_fill_super(struct super_
sbi->vfs_sb = sb;
sb->s_fs_info = sbi;
sb->s_maxbytes = MAX_LFS_FILESIZE;
- sb->s_magic = TUX3_SUPER_MAGIC;
sb->s_op = &tux3_super_ops;
sb->s_time_gran = 1;
@@ -162,6 +161,7 @@ static int tux3_fill_super(struct super_
}
goto error;
}
+ sb->s_magic = *(be_u32 *)sbi->super.magic;
if (sbi->blocksize != blocksize) {
if (!sb_set_blocksize(sb, sbi->blocksize)) {
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)
> 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
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
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>
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? Thanks! Steve
 |
|
|
|
|
|
|
| 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 | 29 | 30 | 31 |
RSS Feed795 |
|---|