Plugin Patch (was Re: creating live virtual files by concatenation)
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 -- Peter van Hardenberg ([EMAIL PROTECTED]) Victoria, BC, Canada pgpmtn3bbb9eH.pgp Description: PGP signature
reiserfs 3 on top of software raid 1
Hi all, I have a question that didn't occur to me until a power failure (eh)... When a journalized file system like reiserfs 3 runs on top on a software raid volume, does the volume give enough (and correct) feedback so that the file system can still guarantee that its metadata will be in a consistant state after a power failure/crash/you name it ? If all disks go back online ? If some don't (but below redundancy amount, of course) ? In short, beside disks resynching, is a fsck also necessary ? Best regards, Pierre. -- .-- Concept Micro > | Vente, Maintenance, Conseil & Audit en micro-informatique | email: [EMAIL PROTECTED] ^ web: http://www.concept-micro.com/
Re: creating live virtual files by concatenation
On 2/27/06, Hans Reiser <[EMAIL PROTECTED]> wrote: > Pretty much any simple basic tool or extension can be lived without. > For them to say that you can do without it is to say nothing. There is All I said was that I don't *think* it will be of much use, that's not to say that it *won't* be. As a read-only thing I can certainly see some uses of it - Maciej pointed out some nice ideas, sure, but wether or not they are actually useful when you try to do real work needs to be tested. I for one need to see it and play with it to determine if it will actually be useful. Let's see an implementation and see how it works out for real... -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html
Re: creating live virtual files by concatenation
Rik van Riel wrote: >On Sat, 25 Feb 2006, Peter Foldiak wrote: > > > >>"sub-file" corresponding to a key-range. Writing a chapter should change the >>book that the chapter is part of. That is what would make it really valuable. >>Of course it would have all sorts of implications (e.g. for metadata for each >>part) that need to be thought about, but it could be done properly, I think. >> >> > >What happens if you read the first 10kB of a file, >and one of the "chapters" behind your read cursor >grows? > > That is why you have magic delimiters, like the colons and newlines in /etc/passwd. You also specify the delimiters in your inheritance syntax. You don't want it to really all be one file, because you want separation of modification times and acls that let users change their own gecos field and etc., but there are times when you want to act on /etc/passwd as one file. >Do you read part of the same data again when you >continue reading? > >Does the read cursor automatically advance? > >Your idea changes the way userspace expects files >to behave... > > >
Re: creating live virtual files by concatenation
Pretty much any simple basic tool or extension can be lived without. For them to say that you can do without it is to say nothing. There is little one actually needs a computer to do, I remember professors explaining to me that they felt essays written on a typewritter tended to be better written (it was probably due to them being written by humanities students.;-) ) than those produced using troff.
Re: creating live virtual files by concatenation
It is our intent to support inheritance and make that working code someday. I encourage anyone who wants to to contribute to the effort. I will not comment on the http optimization stuff in your email, not my area Cheers, Hans
Re: Reiser4 default in Underground Dekstop distribution
Peter Foldiak wrote: >correction: >Sorry, I now see on their site that: >"Underground Desktop 022 ... the filesystem is now reiserfs v3 instead of >reiser4 - which seems not enough stable and fast - and the bootloader is grub >instead of lilo." >(It's funny, their "April" edition was already out of date in early February.) >Peter > > > > Well, we should contact the underground desktop guys and see if we can talk them into trying a later version of reiser4. There was a real turkey reiser4 (both performance and stability) that we let stay out unfixed for way too long, and it seems this was fallout from that. Hans
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
