Questions about pseudo plugins
Hi there: I've been working on the versioning plugin. I will like to know how can i add a pseudo file to a pseudo directory, dynamically. I mean whenever i detect a new version i want to create a pseudo file under /file.txt/versioning/version/s pseudo directory. Another question is about how can I iterate over directories pseudo files. For example how i can iterate over the files under /file.txt/versioning/version/s (remember the files under this directory are pseudo files which are generated dynamically). I know there is a way to add static pseudo files and directories, by adding them to pseudo_plugins array. Perhaps using the linkage field from pseudo_plugin. I've some more questions but i will come later with them. By the way I found this in the patch for kernel 2.6.15: The function init_pseudo receives a _/const char* name /_which is never used. That's all for now. Thanks a lot .. yoanis
Re: Permission denied while accessing pseudos
On Wednesday 15 March 2006 14:04, you wrote: > Yoanis Gil Delgado wrote: > >Hi there. I've been playing around with pseudos and whenever i try to > > access a pseudo dir or file i get a Permission denied error. For example: > > $ ls hello.txt//rwx > > Permission denied > >I also tried > > $ ls hello.txt/..plugins/rwx > > Permission denied > >I also tried to list a missing plugin and i get the same error. For > > example $ ls hello.txt//pepito > > Permission denied > > > >Thanks. > > Hello. > What patch do you use to enable pseudo? I use, reiser4-2.6.15-enable-metas.diff available at the namesys ftp.
Permission denied while accessing pseudos
Hi there. I've been playing around with pseudos and whenever i try to access a pseudo dir or file i get a Permission denied error. For example: $ ls hello.txt//rwx Permission denied I also tried $ ls hello.txt/..plugins/rwx Permission denied I also tried to list a missing plugin and i get the same error. For example $ ls hello.txt//pepito Permission denied Thanks.
Re: BitKeeper
On Tuesday 07 March 2006 12:08, Amit Vijairania wrote: > Definitely... But, I am new to Reiser4 and need some information. > > Thanks, > Amit > > On 3/7/06, Yoanis Gil Delgado <[EMAIL PROTECTED]> wrote: > > On Tuesday 07 March 2006 11:23, Amit Vijairania wrote: > > > Hi! > > > > > > I want to contribute to Reiser4, and would like to dowload latest > > > development source. Namesys.com gives directions for using BitKeeper > > > repositories. Is this the only way to download latest code? > > > > > > Thank you. > > > > > > Amit > > > > if you want to contribute to reiser4, maybe you would like to participate > > in > > the plugin fest. Well if you need some help with the debuggin an all that i can help. I have setup an UML box with reiser4 support.
Re: BitKeeper
On Tuesday 07 March 2006 11:23, Amit Vijairania wrote: > Hi! > > I want to contribute to Reiser4, and would like to dowload latest > development source. Namesys.com gives directions for using BitKeeper > repositories. Is this the only way to download latest code? > > Thank you. > > Amit if you want to contribute to reiser4, maybe you would like to participate in the plugin fest.
Re: Plugin Patch (was Re: creating live virtual files by concatenation)
On Tuesday 28 February 2006 16:53, Marcus Furlong wrote: > > On Tuesday 28 February 2006 12:07, Yoanis Gil Delgado wrote: > >> On Tuesday 28 February 2006 01:24, Peter van Hardenberg wrote: > >> We most take the advance.I suggest to all people interested in this to > >> spent a full weekend creating such a plugin. There is a possibility of > >> failure but. we will gather enough question for the people at > >> namesys and they can share some ligth. Then we spent another weekend and > >> so on... > > > > Yoanis, this is a great idea! We can collaborate via IRC and the wiki and > > share our discoveries. I will join this project. Who else will? > > Count me in too. I think it's a great idea. Any chance of having someone > from namesys on hand to participate as well in case we hit any brick walls? Yes that would be excellent. But we must think in the worst scenerio. We must start walking so when we hit the wall people at namesys said: "This kids really need help" P.D: Reiser please don't let us hit the wall :)
Re: Plugin Patch (was Re: creating live virtual files by concatenation)
On Tuesday 28 February 2006 14:41, Peter van Hardenberg wrote: > On Tuesday 28 February 2006 12:07, Yoanis Gil Delgado wrote: > > On Tuesday 28 February 2006 01:24, Peter van Hardenberg wrote: > > We most take the advance.I suggest to all people interested in this to > > spent a full weekend creating such a plugin. There is a possibility of > > failure but. we will gather enough question for the people at namesys > > and they can share some ligth. Then we spent another weekend and so on... > > Yoanis, this is a great idea! We can collaborate via IRC and the wiki and > share our discoveries. I will join this project. Who else will? Yes IRC is a good way of communication this will bring to life reiser4 IRC channel :). Hope we can get enough hackers. As soon as we have then we must start to organize the "party".
Re: Plugin Patch (was Re: creating live virtual files by concatenation)
On Tuesday 28 February 2006 01:24, Peter van Hardenberg wrote: > Hans, > > you've said that these kinds of plugins should be something a weekend > warrior could tackle. Our group had a real stab and dumped hundreds of man > hours into the project with little effect. Admittedly, we were not > experienced kernel hackers, but we were all comfortable in low-level C and > quite happy to read source. > > I request that a simple plugin be maintained as a standalone patch to > Reiser4 > > Ideally, there would be a small set of these plugins demonstrating how to > create a new plugin which operates within the existing disk structure, and > one that extends the on-disk format in a safe way. > > This would allow interested parties to see in isolation what a Reiser4 > plugin looks like and would further provide a conceptual grappling point > for the development of a new plugin. > > I have been getting requests for just such a plugin to be added to my > reiser4 developer's wiki (http://pvh.ca/trac/wiki/reiser4) at a rate of > about one every two months. A few successful third-party plugins would > hopefully increase interest in this. > > I realise you and your team are up to your necks in serious work on > hardcore lowlevel material, but I believe a brief diversion of some of your > resources would provide a significant reward. > > Right now, the cost-of-entry appears to be set too high for developers > outside your team to approach the project. > > If this information is already out there somewhere, great. I will integrate > it in the R4DevWiki and answer questions as best I can. If anyone out there > disagrees with me about the current difficulty of producing even a simple > plugin, let them prove me wrong with a patch. > > -pvh We most take the advance.I suggest to all people interested in this to spent a full weekend creating such a plugin. There is a possibility of failure but. we will gather enough question for the people at namesys and they can share some ligth. Then we spent another weekend and so on...
Re: creating live virtual files by concatenation
Jan Engelhardt wrote: Now let us say I am creating sort of a virtual text file (code.js) that is a live-concatenation of these files: # concatenate tooltip.js banner.js foo.js code.js Note I am not talking about the cat(1) utility. I am thinking of code.js be always a live concatenated version of these three, so when I modify one file, the live-version is also modified. What puprose I might have? Network-related. Say, I have an HTML file that includes these three files in its code. Try FUSE. Yes that's the best solution. Email me if you have a question about how to accomplish this. Here at our school we have created a fuse filesystem that "glues" files in a single one. If I had a live-concatenated file, I could reference it in the HTML file so that the browser does not have to download three files but just one. This would surely reduce network overhead of downloading the same amount of data but within just one connection, reduce resource usage on the client and possibly (depending on implementation) reduce the cost of accessing three individual files on the server. Have you ever heard of persistent connections with HTTP/1.1? Jan Engelhardt
Re: Authoring a versioning plugin
On Thursday 12 January 2006 06:56 pm, you wrote: > David, > > I appreciate your criticism, but we're not in a flame war. I never > claimed to be an FS expert. Take it easy; you don't have to beat my > suggestion to death. There's no perfect solution, and all feedbacks, no > matter how idiotic or simple may seem, help making a better final > solution. > > my suggestions were burst of the moment, I didn't give 'em much thoughts; > however, all the problems you found could be fixed. Again, I'm not the FS > expert here. > > -B Yes I agree with you Bedros, but i don't think David wanted to beat your suggestion to death. You're suggestions make me thinks things I have not preview. As you say the idea it's to find a good solution.
Re: Authoring a versioning plugin
On Thursday 12 January 2006 02:39 pm, you wrote: > On Thursday 12 January 2006 01:14 pm, you wrote: > > > I'm planning to use a delta techniques for versioning storage (delta > > > compression). The versioning will be at the write level. The versions > > > will be saved in a special directory under the filesystem. I think the > > > hard part is the one related to detecting the changes (a COW it's a > > > possible solution, but i think it's to expensive). I'm thinking a > > > possible solution will be detecting the bytes changing in each write > > > and archiving then as the difference. This introduce some problems > > > like : 1-) What happens if the file shrinks? > > > 2-) What happens if the file grows ? > > > > > > I will send another email with a solution to this problems. > > > > This will not be easy, I look forward to seeing your solution. > Well this is one of the interesting part of the projects. I will not start from scratch, since there is previous work on this area (the delta file system for example, although it's a little old).
Re: Authoring a versioning plugin
On Thursday 12 January 2006 03:02 pm, you wrote: Please remember the plugin it's in an earlier design phase, and the answers > can change, but right now this is what I think: > > I think versioning plugin is a great idea and I bet there're many people > > like me waiting for such a plugin. However, I have few questions; > > > > what happens when I delete a file? should I loose all history of the file > > with such action? > I think the history should go away too, since history will be stored as deltas. > > > if there's an undelete plugin, what kind of hooks needed so undelete > > recovers the full state of the file with history. > Undelete plugin is for future work. right now I'm thinking that if there is mechanism to track down the versioning info of a file no matter the directory it's located, then this should not be a problem. > > another concern is backup; if I backup the file or the entire directory > > (or drive), is it transparent to the backup app, or something extra > > needed to be done to backup the history of the file? > don't know right now. will come with more answers on next days. > > > if you store all the history in a sub direcotry let's say .rev and make > > it generic (and hence visible) to everyone, the above problems will go > > away. > > > > for example filename.ext deltas could be stored in .rev/filename- > > rev-date-time.delta with base rev in .rev/filename-rev-date-time.ext > But what happens if i type: $ mv filename.ext ../ then the entire file revision tree must be copied. that's why i mention the idea of mechanism to track down the versioning info of a file. > > > correct me if I'm missing something, because I don't know the plugin > > mechanism of reiser4. Thanks a lot for the questions.
Re: Authoring a versioning plugin
On Thursday 12 January 2006 02:34 pm, you wrote: > On Thursday 12 January 2006 01:44 am, you wrote: > > Hans Reiser wrote: > > > > > > > > > I am skeptical that having it occur with every > > >write is desirable actually. > > > > > > > Consider the case where you type cat file1 >> file2. This will produce > > a version of file2 for every 4k that is in file1, because (well I didn't > > look at the bash source, but I would guess) it appends in 4k incremental > > writes rather than one big write. Versioning on file close makes more > > sense, but I suggest manual control using the /checkin pseudofile, > > and then we can reasonably make it the default plugin for the whole FS > > (write it so that it calls the other plugins so that when we change the > > other plugins we don't need to change your code to do it). People who > > don't want versioning will simply never touch the checkin pseudofile. > > Make sure that for that case there is just an if statement condition > > check as overhead, and there will be no reason to not make versioning > > the default plugin that happens to do nothing unless you use the checkin > > pseudofile at least once during the life of the file. > > > > hmm, maybe /snap is better than /checkin ? Well, let's decide > > that once the code is written;-) > > > > Do you agree with my points here? > Yes I agree with your points. Still, i will like that some files have auto versioning.
Authoring a versioning plugin
This are the intentions: To write a versioning plugin that will allows the file system user to easily revert the files under versioning to a some previous state. The plugin will allow to revert the file state, based on revisions number and date modifications(and not sure about this one). There will be a special pseudo file named "previous" that will return the previous version of the file. The final result should allow to the the following actions: $ echo 1 > myfile.txt (let's say we make this command at Wed Jan 11 16:53:55) $ echo 2 > myfile.txt (let's say we make this command at Wed Jan 11 16:54:57) $ echo 3 >> myfile.txt (let's say we make this command at Wed Jan 11 16:55:59) Suppose you want the latest version, then you type: $ cat myfile/.../previous Some other content Or you want the n-th version, then you type: $ cat myfile/.../1 Some content $ cat myfile/.../2 Some other content $ cat myfile/.../3 Some other content Some more content $ Or the version nearest to some date, then you type: $ cat myfile.txt/.../Wed\ Jan\ 11\ 16:50 Some other content Also , there will be an special attribute named under_versioning(or something like that), that will tell if the file is under versioning. This plugin will not track directories version, although it's a future plan(I think this should be mixed with some undelete plugin). I'm planning to use a delta techniques for versioning storage (delta compression). The versioning will be at the write level. The versions will be saved in a special directory under the filesystem. I think the hard part is the one related to detecting the changes (a COW it's a possible solution, but i think it's to expensive). I'm thinking a possible solution will be detecting the bytes changing in each write and archiving then as the difference. This introduce some problems like : 1-) What happens if the file shrinks? 2-) What happens if the file grows ? I will send another email with a solution to this problems. I've also plans to extent the documentantion of plugins creation in reiser4 with the experiences of this project. I'll be working in this plugin for more than 4 months. If you're interested you're welcome to the the team(just me right now :D ) Well... I think this is all (for now :D ). Please let me know what you think.
about reiser4 hacks
Thanks a lot for the comments in the mailing list, quite useful. i can see you guys are going deep in reiser4 code. meabe i can join your team, and research together. i studying resier4 too, 'cause i want to do my thesis in filesystems and especially in reiser4.that's all keep hacking ..
Re: error compiling reiser4 for kernel 2.6.13.1
On Thursday 20 October 2005 09:06 pm, Yoanis Gil Delgado wrote: > Hi i just downloaded the 2.6.13.1 kernel source and the reiser4 patch for > this kernel (reiser4-for-2.6.13-1.patch). When compiling i get the > following error: > > LD fs/reiser4/built-in.o > CC [M] fs/reiser4/debug.o > In file included from fs/reiser4/lock.h:15, > from fs/reiser4/context.h:14, > from fs/reiser4/debug.c:25: > fs/reiser4/txnmgr.h: In function `spin_atom_init': > fs/reiser4/txnmgr.h:512: error: duplicate case value > fs/reiser4/txnmgr.h:512: error: previously used here > fs/reiser4/txnmgr.h: In function `spin_txnh_init': > fs/reiser4/txnmgr.h:513: error: duplicate case value > fs/reiser4/txnmgr.h:513: error: previously used here > fs/reiser4/txnmgr.h: In function `spin_txnmgr_init': > fs/reiser4/txnmgr.h:514: error: duplicate case value > fs/reiser4/txnmgr.h:514: error: previously used here > In file included from fs/reiser4/context.h:14, > from fs/reiser4/debug.c:25: > fs/reiser4/lock.h: In function `spin_stack_init': > fs/reiser4/lock.h:198: error: duplicate case value > fs/reiser4/lock.h:198: error: previously used here > In file included from fs/reiser4/znode.h:16, > from fs/reiser4/tree.h:15, > from fs/reiser4/super.h:9, > from fs/reiser4/debug.c:26: > fs/reiser4/jnode.h: In function `spin_jnode_init': > fs/reiser4/jnode.h:344: error: duplicate case value > fs/reiser4/jnode.h:344: error: previously used here > fs/reiser4/jnode.h: In function `spin_jload_init': > fs/reiser4/jnode.h:348: error: duplicate case value > fs/reiser4/jnode.h:348: error: previously used here > In file included from fs/reiser4/super.h:9, > from fs/reiser4/debug.c:26: > fs/reiser4/tree.h: In function `spin_epoch_init': > fs/reiser4/tree.h:169: error: duplicate case value > fs/reiser4/tree.h:169: error: previously used here > In file included from fs/reiser4/debug.c:26: > fs/reiser4/super.h: In function `spin_super_init': > fs/reiser4/super.h:379: error: duplicate case value > fs/reiser4/super.h:379: error: previously used here > make[2]: *** [fs/reiser4/debug.o] Error 1 > make[1]: *** [fs/reiser4] Error 2 > make: *** [fs] Error 2 > > Here is the output from the gcc version: > sena:/usr/src/linux# gcc -v > Reading specs from /usr/lib/gcc-lib/i486-linux-gnu/3.3.6/specs > Configured with: ../src/configure -v > --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr > --mandir=/usr/share/man --infodir=/usr/share/info > --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared > --enable-__cxa_atexit --with-system-zlib --enable-nls > --without-included-gettext --enable-clocale=gnu --enable-debug > --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc > i486-linux-gnu Thread model: posix > gcc version 3.3.6 (Debian 1:3.3.6-7) > > One more thing, i patched the 2.6.13 kernel (not the 2.6.13.1) and i got no > compilation error. Thanks and best wishes...yoanis Well after "googling" a little and found not ansrwers y disbable de debug support and it works. so the problem it's partially solved. now i want to know why the debug support generated such errors?
error compiling reiser4 for kernel 2.6.13.1
Hi i just downloaded the 2.6.13.1 kernel source and the reiser4 patch for this kernel (reiser4-for-2.6.13-1.patch). When compiling i get the following error: LD fs/reiser4/built-in.o CC [M] fs/reiser4/debug.o In file included from fs/reiser4/lock.h:15, from fs/reiser4/context.h:14, from fs/reiser4/debug.c:25: fs/reiser4/txnmgr.h: In function `spin_atom_init': fs/reiser4/txnmgr.h:512: error: duplicate case value fs/reiser4/txnmgr.h:512: error: previously used here fs/reiser4/txnmgr.h: In function `spin_txnh_init': fs/reiser4/txnmgr.h:513: error: duplicate case value fs/reiser4/txnmgr.h:513: error: previously used here fs/reiser4/txnmgr.h: In function `spin_txnmgr_init': fs/reiser4/txnmgr.h:514: error: duplicate case value fs/reiser4/txnmgr.h:514: error: previously used here In file included from fs/reiser4/context.h:14, from fs/reiser4/debug.c:25: fs/reiser4/lock.h: In function `spin_stack_init': fs/reiser4/lock.h:198: error: duplicate case value fs/reiser4/lock.h:198: error: previously used here In file included from fs/reiser4/znode.h:16, from fs/reiser4/tree.h:15, from fs/reiser4/super.h:9, from fs/reiser4/debug.c:26: fs/reiser4/jnode.h: In function `spin_jnode_init': fs/reiser4/jnode.h:344: error: duplicate case value fs/reiser4/jnode.h:344: error: previously used here fs/reiser4/jnode.h: In function `spin_jload_init': fs/reiser4/jnode.h:348: error: duplicate case value fs/reiser4/jnode.h:348: error: previously used here In file included from fs/reiser4/super.h:9, from fs/reiser4/debug.c:26: fs/reiser4/tree.h: In function `spin_epoch_init': fs/reiser4/tree.h:169: error: duplicate case value fs/reiser4/tree.h:169: error: previously used here In file included from fs/reiser4/debug.c:26: fs/reiser4/super.h: In function `spin_super_init': fs/reiser4/super.h:379: error: duplicate case value fs/reiser4/super.h:379: error: previously used here make[2]: *** [fs/reiser4/debug.o] Error 1 make[1]: *** [fs/reiser4] Error 2 make: *** [fs] Error 2 Here is the output from the gcc version: sena:/usr/src/linux# gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux-gnu/3.3.6/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --enable-__cxa_atexit --with-system-zlib --enable-nls --without-included-gettext --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux-gnu Thread model: posix gcc version 3.3.6 (Debian 1:3.3.6-7) One more thing, i patched the 2.6.13 kernel (not the 2.6.13.1) and i got no compilation error. Thanks and best wishes...yoanis
