A brief thread on the lkml discussed whether or not Reiser4 would soon be stable enough to be merged into the 2.6 kernel as an ‘experimental filesystem’.
Linux: Reiser4 In 2.6?
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
now just get some software to make use of it!!!
The world would be a better place if everyone used reiser.
Does anyone know if reiser4 has disk quota support?
however as old hat Linux users say “but you need flexability and choice”
what ever, I say make a nice interface that you can plug in diffrent modules to the DE that will connect it well to the diffrent File systems, etc.
cant disk quota support be filesys indepenend (just as journailing) in a layer above, and any filesystem can/must? suport this then?
I’m writing a file manager that will use Reiser4 attributes if you got em. I’m aiming at something between M$’s Explorer + BeOS’s Tracker, all for Linux…
Theres some alpha screenshots on my site…
Looks and functionality! You have some nice work. By the way, where is that ‘X’ from? Kind of looks familiar.
In a recent interview, you mentioned that not only XFS, but also ReiserFS has support for the BeOS-style ‘live queries’. Could you elaborate on this a bit? How far along are userspace tools to take advantage of it?
2.7 will not be a stabl release, but instead a developer’s testing release right?
Anyway, I thought reiser 4 would actually be in 2.6, but I guess I heard it wrong.
I didn’t mention it, I just asked for it if they have such support. Even if they do though, there are no user-space programs to take advantage of these advanced features, because most file managers and apps prefer to play it safe with legacy file systems instead of biting on these new features and supporting them.
IMHO, it should be merged into the tree as soon as possible. If it is feature complete, why not merge it, label it “experiemental” until such time that it is deamed “stable” enough for general use. IMHO, from what I have seen so far, the only people who have suffered from so-called “corruption” using ReiserFS have been users who have buggy chipsets, those of us who have stuck with good brands like Intel, ServerWorks and AMD haven’t see any of this.
Hopefully, with enough testing, it will get stable around 1/2 through next year, along with advances on the desktop, it should become quite an interesting filesytem. Leaving the archaic world of clusters and so forth has made life alot easier for all concerned.
No I don’t use exotic chipset, just a Dell laptop which did hang from time to time because 2.4.20 21 or 22 were not nice with it.
I was so sick of it that my main partition was formated with ext3.
Same happend to me with ext{2,3}, xfs, fat{12,16,32}, ntfs, and reiserfs (of course)
I hope it’s faster with large files. I made the mistake of using reiserfs(3.6) on a partition that I store large video files on. I have low system specs so every bit of speed is nescesary, and now I’m just below what is needed to play video at full speed. Maybe it’s the high CPU usage of reiserfs, or maybe it’s because I’m now using 2.6 kernel(was 2.4 kernel, and etx3, last time video was perfect speed). I’m also using newer mplayer/xine versions. So I can’t verifiably say that reiserfs is my source of slowness, but it’s likely. I love it’s speed for small files though!
Use XFS for that partition. It’s pretty impeccably reliable, and it’s optimized for large media files. Many use it for databases.
>>By the way, where is that ‘X’ from? Kind of looks familiar.
Thats the X that is inserted by default when no icon is called out by the program. Its the X windows symbol…
I use XFS, is very fast. Much faster than Reiser4, at least. And ext2/3. Why on earth would anyone think that Reiser is good for large files?
I’d just wish there would be fewer kernel releases with all that experimental stuff. No bugs – that is.
disk quota support is filesystem independent, but filesystems can support it in a native way, resulting in a kinda cleaner solution.
reiser4 is not only about speed anymore, it does data journalling (the data you want to write is kinda cached and changes are made when you’re finished – so if your system gets a power failure, your data is not damaged, it is the new version if youre lucky or remains the old version if youre not, but its not corrupted).
in a normal way, this means twice the write duration (first written to the journal than to where it belongs to). this is kinda slow. reiser4 moves the journal to avoid this and have a 1,2x duration.
if you don’t want experimental stuff, just use that one and only “show me experimental choices” switch at the beginning of your kernel configuration.
“I use XFS, is very fast. Much faster than Reiser4, at least. And ext2/3. Why on earth would anyone think that Reiser is good for large files?”
XFS is good atexecuting large binaries. There are other ways to improve that too, like HDDparm and Prelinking. In the end a box with some other FS than XFS with properly tweaked HDDparm and Prelinking can turn out to be faster than XFS without these 2. Goes the other way around too. Therefore, i’d advice to look at more possibilities to make a computer faster than solely the choice of FS. It also depends on what you’d like to aim. ReiserFS would be very good with /var/spool/mail but then again we use Maildir.
People, please include the version of ReiserFS you’re talking about. Not mentioning that is the same like saying: “Linux doesn’t support my driver”. Linux 0.12 doesn’t support my USB key either
. Here’s a ReiserFS4 benchmark (by the ReiserFS people):
http://www.namesys.com/benchmarks.html
Here’s an overview about ReiserFS4 (by the ReiserFS people): http://www.namesys.com/v4/v4.html
Though i’d take the “why is it great for you with some salt:
It shipped before the other journaling filesystems for Linux, and is the most stable of them as a result of having been out the longest. We must caution that just as Linux 2.6 is not yet as stable as Linux 2.4, it will also be some substantial time before V4 is as stable as V3.
Doesn’t proof anything by itself. Those other FSes could have been tested via other ways instead of being in the main stable kernel tree. You’ll need more extensive arguments + proof to back this up imo.
I don’t really care wether it’ll be in 2.7, 2.6/experimental or a patchset. What matters to me is the best way and the arguments for that. Whatever it is, i hope that road is chosen — and i don’t know which one it would (best) be.
Btw here’s a driver which allows one to access (read only) a ReiserFS from Windows: http://freshmeat.net/projects/rfstool not sure for which version(s).
(speaking about ReiserFS3 in the first paragraph)
“reiser4 is not only about speed anymore, it does data journalling (the data you want to write is kinda cached and changes are made when you’re finished – so if your system gets a power failure, your data is not damaged, it is the new version if youre lucky or remains the old version if youre not, but its not corrupted).
in a normal way, this means twice the write duration (first written to the journal than to where it belongs to). this is kinda slow. reiser4 moves the journal to avoid this and have a 1,2x duration.”
Readed. I have a few questions: can you explain to me how this implementation is different than softupdates? How does ReiserFS{3,4} delete data? Are there BSD implementations of ReiserFS{3,4}, XFS et al?
Has anyone here done analysis on how and which journaling FS has the best performance with a CFS’ed (if so, which one) environment?
What i’d also really like is to run such FS inside another one to test and benchmark its features. Does anyone know such tool?
Live queries could be handled with simple symlinks, ie:
ln -s “/path/to/reiserfs-mounted-drive/this-is-the-query” livequery
Then you’d simply do “dir livequery”.
I think the difference is, that Reiser4 *does* write the data, but it writes it to “free” space not overwriting anything. after everything is finished, it marks the new space as where to find that data and marks another space as data journal space.
If I understood correctly, softupdates only let the data remaining in RAM. So it’s lost. with reiser4 you should be able to recover the actual-on-change data, while providing that the older data is not corrupted by it.
problem is, that this method is fragmenting. so with reiser4 comes a such called repackager which does defragmenting (and other stuff).
this is kinda performance problem for databases, too. Hans Reiser admitted that and a solution could be special plugins used by databases telling the file system to handle their data placing another way.
If I remember correctly from Hans Reiser’s speech at LinuxTag 2003, files are deleted by marking them as deleted. Don’t know more details.
XFS should be there für *BSDs, Reiser(3/4) I don’t know.
I’m sorry if I misunderstood you and this isn’t what you searched and it’s very obvious for you:
to have a filesystem running inside another one, you could create a file piping /dev/zero into ‘dd’ (see man dd) with the size of the guest filesystem.
than you can makefs.* on that file.
now you can mount it with -o loop
(you need loop devices enabled in your kernel (is also to be compiled as a module)
is there any patch for stable linux 2.6.0?