I was reading through the changelog for 2.6.9-mm1 and noticed there was a comment about whether or not Reiser4 would be in 2.6.10. Here's a place to voice your opinion one way or another.
I support linux in the enterprise, and I use it at home, and I think it's already overdue in the kernel. If it's not heavily used already, it's going to be once it's considered stable. I've seen in various places where users have been claiming for months that it's stable. I wouldn't go that far, a filesystem has to undergo a lot of testing before I even remotely consider it stable (I learned my lesson on Reiser3) and trust critical data to it, but on the other hand, I have numerous test boxes at work and at home to work with. Obviously, just because it's in the kernel, doesn't mean it's being "certified" as stable, and there's plenty of less relevant stuff or less used stuff that is put in there and marked experimental (not criticizing or complaining, just making a point).
Andrew mentioned the chicken or egg syndrome in he changelog and I think that with something like this, the sooner it gets in the stable kernel, the sooner more people really start using and testing it. A lot of people stick to a particular patched kernel, such as ck sources, wolk sources, (just examples, I haven't checked those recently to see if they already have Reiser4 patches)etc, and aren't going to switch to mm-sources, or try merging the patch just to test a single filesystem.
| Shared swap partition | 5 hours ago | Linux general |
| high memory | 2 days ago | Linux kernel |
| semaphore access speed | 2 days ago | Applications and Utilities |
| the kernel how to power off the machine | 2 days ago | Linux kernel |
| Easter Eggs in windows XP | 2 days ago | Windows |
| Root password | 2 days ago | Linux general |
| Where/when DNOTIFY is used? | 2 days ago | Linux kernel |
| How to convert Linux Kernel built-in module into a loadable module | 2 days ago | Linux kernel |
| Linux 2.6.24 and I/O schedulers | 2 days ago | Linux kernel |
| USB Driver -- Interrupt Polling -- A Little Help Please | 2 days ago | Linux general |
reiser4
I have been using reiser4 since the 2.6.0 test series, and despite a few 'format' changes in early versions, i just have now no problems at all with it. It feels way faster than anything i have used, and i am coming from XFS too. Do i consider it stable ? Enough to give 320 gigs of my 360 to it. Never had a bad problem, and far less troubles than early reiser3 filesystem ( aka no corruption of the open files on crash! ).
The only regret is to not find it in mainstream kernel yet ( even tagged as experimental ), so the usual patching ceremony has to take place.
Is it me, or it seems Hans work gets always integrated and declared stable in the kernel quite late ? I remember reiser3 being tagged experimental in 2.4.X for ages where it was in fact perfectly usable and reliable way before. So yes, please, integrate reiser4, experimental or not =).
how does Reiser4 behave
when there are bad blocks on the medium ?
The only FS I saw so far that can handle such a situation is EXT2/EXT3, which can blacklist blocks and can receive a badblock list at FS creation.
I consider this feature the first important feature that, if it lacks, will prevent me from using a FS (hardware failure ALWAYS occurs). Even FAT can handle such a situation, provided the bad blocks are not in the fat itself or in the partition table (in such a case, only Linux can use the disk by the way!).
Does anyone tried to do the same with other, more recent FS (Reiser3 & 4, XFS, JFS, etc.) ?
One could make some tests with a device mapper device with holes on the device, but I would be happy if anybody ** who knows** could answer me.
With modern disks
the remapping of "almost failed" blocks happens automatically. If you have bad blocks which actually look like bad blocks to the OS then you need to get a new disk, because that is a sure sign of impending doom.
Besides, this is not something which the file system should need to know anything about -- the failure occurs at a lower level than the file system should have to care about.
Finally: There is definitely an experimental Device Mapper module which can actually do bad block remapping out there somewhere; I know nothing about its features so I can't comment on those, but you might try googling a bit.
With old disks
I'm still concerned with that problem.
I already had several IDE disks with all remapped extra tracks filled and still two or three big zone unusable, and that still works after several years.
dm is what I would preconize now, but I can't know now which tracks could fail at the beginning of the life of such a bad disk, and I EXPECT the fs not to crash completely.
Moreover, saying something should not happen won't prevent it from happening.
Sorry,
Sorry, but your expectations are unrealistic. Almost no new file systems have this remapping capability -- it's just not worth putting the every into *every* file system when you can put it into *one* generic device mapper layer.
Btw, the DM module could quite easily "remap" blocks dynamically (as I said, I don't know whether it actually *does*) -- the VFS layer would just get an error on the original read and the block would be marked bad by the DM.
Hard Disk reliability, speaking from experience
we sometimes deal with as many as 100 computers per month, and this is our experience:
Seagate drives get bad sectors frequently and come nowhere near automatically mapping them as bad. Over 50% of Seagate drives we test have errors.
Western Digital drives get bad sectors, don't notice that they're bad, and then completely fail. Then they give S.M.A.R.T. errors. Over 50% of WD drives we test have errors.
Hitachi drives get bad sectors, but they map over them beautifully. Under 10% of Hitachi/IBM drives we test have errors.
Maxtor drives that are packaged with HP systems (also known as Class B, which is just a codename for Grade B) fail frequently and totally, usually not from bad sectors. 100% of Maxtor Class B drives we test have errors.
Maxtor drives above 2GB and sold as retail drives have a 0% failure rate. (I'm not making this up. We've seen NO bad Maxtor above 2GB other than Class B fail. If you want to know if your drive is Class B, the best way to find out is to go to the Maxtor site and do a warranty lookup. If it says your drive is under warranty or is past warranty, then you're okay. If it says to contact the PC vendor, you may want to ask Maxtor themselves about this message. They will say whether it's supposed to be in an HP or not.)
Fujitsu drives rarely fail, but we also rarely see them. Only one of the Fujitsu drives we have tested had errors.
Unfortunately, we have to say that drives have nowhere near the speed nor stability that one would expect from them considering modern manufacturing practices. However, we often surprise people with how often crashes are the fault of bad RAM.
Nevertheless, I use Reiser4, and so far it seems pretty stable. I just remember to keep my precious data backed up on CD. Never trust just one media. I've seen even mirroring RAID devices go bad just from controller board failures, so nothing is foolproof. Reiser4, tho, seems to take care of what it's responsible for pretty well.
Strange. I have had IBM, Max
Strange. I have had IBM, Maxtor, and WD all die on me, but Seagate has always worked like a champ. I'm not a computer tech...just a more advanced user than the avg. I must have the worst luck ever I guess.
I think I agree that it is best not done in our layer
The device remapper really sounds like the clean place to do it. Especially if someone created a clean interface between the remapper and the badblocks program.
badblocks, dm, and filesystems
I realize this is an old thread, but I wanted to insert my $ worth on the topic.
I’m in the process of building a huge disk server, the server it is replacing uses ext3 file-systems. Initially I started building this new server using 250GB drives like I had used on the old server, but tried Reiser3 instead of ext3. I found the initial check / mount of the Reiser3 partitions took a very long time at system boot even before anything was stored on them. This was on a 233 MHz Pentium 128 MB RAM running Gentoo 2006.0 I recompiled using optimizations specifically for the Pentium class processor and my system hardware.
I decided at that point that my Pentium hardware was beyond help, so I recently started over with modern hardware. I caught an excellent deal on some 500 GB drives, and recalled seeing an article about how the various file-systems compare when dealing with huge files and their theoretical file-system size limitations. The server will be used to store huge CD / DVD ISO’s and MD5 / SHA1 hash verification files. So I need a file-system that can be tuned to efficiently service these huge files while still being space conscious for small text files. The article was very positive about Reiser4, but XFS stood out as the obvious choice since it is has seen a little more support by major distributions.
I received the first batch of hard drives yesterday, so last night I setup a system to do some burn-in testing on these new drives. The first thing I noticed was the lack of the –c –c bad block testing option when creating the XFS file-system. As was mentioned earlier in the thread, modern hard disks will remap bad sectors, but only when a write failure occurs. My old server had a drive fail when the LVM recently started storing data on it. When I built that system all I did was write zeros to every sector. I now burn-in new drives using the badblock program’s ability to write patterns to every sector. I was forced to separately run the badblock program. Fortunately none of the drives have had any hard failures that will need to be mapped into the file-system, but eventually they will occur, and that got me wondering how to deal with them when they do occur, thus I found this discussion.
I agree that modern hard drives contain firmware logic that is supposed to re-map bad sectors. SCSI drives seem to do a little better with this than their ATA counter parts, but I have to admit my experience with SCSI is limited to the smaller drives that just do not have the same rate of inevitable failures that the larger capacity drives experience. The SMART firmware seems to deal with random manufacturing defects quite well, however, SMART is not perfect.
I was unfortunate to have owned 12 of the IBM DTLA drives that had the big class action lawsuit over failures a few years back. IBM denied it was a firmware problem, but I believe that the SMART logic was the source of the problem on my drives. I know for a fact that cabling and OS disk driver LBA limit problems caused several re-mapped sectors on these drives. I wish there was a way for me to reset SMART so that some of these otherwise good sectors could have been recovered. As it stood many of these drives had all spare sectors re-mapped. My only choice would have been to use some kind of bad block mapping capability.
I also salvaged a 60GB drive that crashed on a friend. Windows could not deal with a band of bad sectors this drive had, but I was able to use Linux to locate the starting and ending addresses where this band of bad sectors was located. I then created a partition at the beginning of the drive that ended just before the bad area, and another that started after. The drive has continued to work flawlessly ever since.
As was mentioned earlier, some types of media are just not intended to be smart and a bad block facility is still needed for such devices. Another mentioned the use of a device mapping layer. As attractive as that sounds, such a mapping device driver layer would still need storage to know what needs to be remapped, and this is why the capability to mark blocks as bad has historically been a feature of the file-system data structures.
Exo
Enjoy your XFS
Perhaps you can hire the former SGI (bankrupt) employees who used to maintain it.
I tried XFS only because someone at a LUG "recommended" it. Then it lost my customers data. Now sometimes I read some Slashdot articles and _every_ single response is incorrect, but modded up to +100. So the so-called Linux community is very weak, everyone is free to have an opinion even if they know nothing about the subject. I prefer something like an "experts exchange" where you get points only if you give [verifiably] correct answer.
I've had essentially no problems with Reiser3. Yes, his current legal difficulties are a concern. But if you write good code, someone does not need to fix it all the time.
If I really do not like you I will recommend for you either Windows Vista Ultimate, Windows Small Business Server, or XFS file system.
going with ext3 for now
As you can see in my original posting, I'm concerned about the fs' ability to cope with bad sectors as my experience with S.M.A.R.T.'s ability to map alternate sectors has been disappointing, I went with the only file system that allows me to run badblocks in the more comprehensive write pattern testing, which is ext3. It appears that Reiser3 does allow the passing of badblock information during mkfs, but this option appears to be gone for Reiser4. JFS appears to support a single -c for badblock testing, but says nothing about if this is the read-only or the write patterns test, and no mention of a way to import a separately created list of badblocks.
I found that ext3 supports 4096 byte blocks on my 500 GB drives so, unless I try storing an ISO for a Blu-ray disk, I will not be hitting any immediate file size limitations.
Exo
XFS & bad blocks
I recently bumped my laptop and 8 consecutive blocks were damaged. My XFS root filesystem wouldn't mount, preventing me from booting. XFS relies fully on the disk drive firmware remapping bad blocks (the drive reserves a few blocks for such eventualities); XFS has no badblock handling of its own. Unfortunately my drive (like most others?) only remaps the blocks when a write fails, not when a read fails. I had to boot with a rescue disk, run "badblocks" to find the damaged blocks, then run "dd" to write zero to those blocks. I ran an "xfs_repair" to be safe. After that all was good again.
Which do you think is better: handling bad blocks in the disk drive or in the FS?
both
Remapping in hard disk is a way to tell "OK, we cannot guarantee 100% bad blocks free disks, therefore we provide 105% of the official capacity and do the trick for you". I therefore expect ALL disk to have problems.
But whatever the device does, I want my fs be secure, that is have redondant metadata (every fs does this, even FAT, but FAT 2 and more are rarely used by MS'OSes :-) and being able to blacklist blocks in these metadata.
Data security implies taking failures into account at each level (hard, fs/os, applications). With Ext2/3 I know the only problem can be applications (that is, my way of creating files and directories in my case).
If you want reliability,
use RAID and backup.
Grandparent was a laptop, so
Grandparent was a laptop, so only 50% of your post applies. The other 50% is not necessarily applicable, as the data was 'there' and unaffected, it was just that the fs would not mount. I believe the measure of a good FS is as dependant on its toolchain as it is engineering, performance, and redundancy merits.
Thank you for your time,
Frank Russo
Reiser3 can do that, so proba
Reiser3 can do that, so probably Reiser4 too, either now or in the future. See: http://namesys.com/bad-block-handling.html
Well, from some experience, I
Well, from some experience, I've found that its way easier to extract data from a failed ext3 disk than a failed reiserfs3 disk.
Well, I just answered the que
Well, I just answered the question which was asked, I said nothing about how well bad blocks are handled when they happen runtime, nor how easy it is to recover data from a bad disk. I don't have any experience with either reiserfs or ext data recovery.
Thanks for your answer
The links you gave answers all my questions!
medium errors vs xfs
My hdd started to fault yesterday, and I use xfs, so I can say from experience, that at first glance nor xfs, nor xfs_replair is designed to handle such problems. The system was not responsive when the first faults occured, and xfs_repair just says "xfs_repair: read failed: Input/output error". my guess is that SGI never came across a read/write error, since they have raid5 everywhere, ;-)
as for reiser 3, some years ago I had a faulty drive where I was using reiser with no problem, I didn't even notice anthing for quite a while.
yes indeed, i was very bummed
yes indeed, i was very bummed that resier4 was not included with 2.6.10. especially after it was experimentally included with previous versions, i was rather shocked that the decision was made to hold off on it. oh well, i guess they're the pros, right?
Network Admin
I am a linux network administrator and I trust and love reiser4. THe performance differences are great, they need to keep this in the kernel. What is linux without new ideas anyways....cough windows....
may be
Don't remember any big FS benchmarks threads in lkml since 9/2003, may be FS war finished and RedHat (ext2/ext3) format win ? Recently i get second 200Gb HDD. I try to compile 2.6.X-mm3 with Reiser4, and after 5 hours of compiling (Celeron 333@418) got network problems ( my bad, enable risky MMIO or such), then remember that ext3 work in any possible kernel, I just do mkfs.ext2. Now I have free time and want to fix nic problem but 80% of HDD used. That is real story. There is no ext2->reiser4 converter like NT fat32->NTFS, seems do not in near future, Hans say that Namesys have finance problems and he even do not look at code untill problems resolved. I look at Reiser4 project since begining and there is always some srange stories ( once Hans have problem with traveling from Russian Federation to USA, then one of main coders leave Namesys, then Hans claim about huge margin in benhcmarks that never be approved by real-life tests by independent testers). I want that reiser4 be included in mainline ASAP that more people play with code and free Hans for some current problems. Linus, reiser4 is so scientific, so fresh, so cool. Make some new independent benchmark, place on any site and hit count will rise to infinity. There is less and less people that compile -mm kernel, give it a chance!
Conversion between ext2 and reiser4
There is a program (convertfs) which can convert between any two file systems with write support in Linux, provided that the original file system supports "holes" (both ext2 and ReiserFS do). It works by creating a file in the old filesystem, making a filesystem inside it, and then moving all the files from the old filesystem to the new one. There are many more structural differences between ext2 (or even ReiserFS) and Reiser4 than there are between FAT32 and NTFS, making a direct translation between the two systems difficult at best.
Yes for Reiser4 in 2.6.10
I've been following the Changelogs a bit and there haven't really been that many Reiser4 patches since it was first included in -mm.
So I've been trying out the -mm kernels to see if Reiser4 can live up to all the hype, but the -mm sources are not always stable enough for my liking. I'm not exactly a kernel hacker either, which makes it difficult sometimes to figure out where the problem lies. Having only one box, on dialup, doesn't make things any easier.
I have to say that I haven't had any fs corruption problems or seen anything which obviously pointed to Reiser4 while I was running -mm.
Having Reiser4 in 2.6.10 would definitely help to get more people _using_ it, but I'm not sure that it would help to track bugs, since the people who want to _test_ it, have already done so. The people who want to use it, like myself, generally do not have the skill to help debug it.
The exclusion of Reiser4 is more a question of politics and doing things "The Right Way" (tm) from a technical perspective, than it is about the filesystem stabilising, IMHO.
beyond unix semantics
Im also using reiser4 but I need functionality from reiser4 semantics. In the meantime im using log structured embedded db tables to make up for the lack of semantics and speed in the current fs's available. Im emulating an fs on top of another fs. At least its working for me now.
They're broken
Actually, I too love the idea of new semantics. However, when they come at LKML first time (years ago), Linus said "Yes, files can be directories". Now, however, a very big problem surfaced.
Basically, Hans Reiser didn't absolutely think very deep about the fact that you can hardlink a file. With R4, a file is a directory. Now, hardlinking a directory creates a lot of problems to Linux, and Unix in general. See earlier discussions on this site and lwn.net.
Is this solvable? I think Hans has no clue yet. And the solution is likely to cause instability to every Linux FS, since it will probably require touching heavily the VFS.
I.e., even if Reiser4 is stable, Reiser4 + this patch probably will have to restart stabilyzing again.
Also, it happened more than once, even with R4, that they weren't finding bugs, told this and got new reports.
RE: They're broken
Hans said Namesys could not hit any bugs anymore! And was waiting for that before he would even consider asking for reiser4 to be included in the kernel. He went on saying that he expects bugs reports to come in when it got into -mm.
Infirit
Been using R4 for months and
Been using R4 for months and would like to see in kernel.
Please?!
Reiser4 is a very kick-ass FS. IMHO, the sooner it's in vanilla 2.6, the better....
It should be, as EXPERIMENTAL
I think it should be in 2.6.10, marked as EXPERIMENTAL.
If there are bugs, they WILL be fixed, being in the stable kernel or not. After all it's a filesystem, not a webcam driver or something like that...
Linux is about choice
I don't think this has to be a big issue. If you want to use reiser4, fine. If you don't want it, fine too. I just don't like patching my kernel again (I already have several patches applied to 2.6.9 vanilla).
Mark it as experimental. However I use some experimental kernel options by default so maybe it should be marked "very experimental". When a filesystem is released by its developers and tested by kernel hackers I consider it stable enough for my desktop. I don't know many people that are going to patch their kernel to use a new filesystem. So if you want it to be used extensively include it as experimental.
my vote
include in kernel:
1) reiserfs 4 - yes
2) fascist Torlvads - no
( 2) is about change from monarchy to democracy )
I vote yes!
I've been running my work desktop with a reiser4 root for about 4 months now. The power has gone out several times and X has locked up a couple times (massive load/nvidia drivers) and I had no corruption. I remember thinking it was noticably faster when I first installed, though that could be a placebo effect. I'm currently bootstrapping (gentoo) my new dothan notebook with a reiser4 root and its running fine so far.
I know Hans Reiser grates on some of you kernel devs, but please recognize that there is plenty of demand for it, and if there are no great technical reasons for not including it as an experimental option- PLEASE do it!
reiser4 kernel 2.6.10
I have been using reiser4 since the 2.6.8.1 days and find it much better than all the rest of the filesystems. I used XFS and ext3, but I find myself going back to resier4 all the time. XFS is VERY LOUD and ext3 seems to be a little slower than reiser4. I can only hope that kernel 2.6.10 will include support for reiser4 atleast as experimental. I know Suse uses reiser4 and Linspire so I don't see why Linus won't include it in the 2.6.10 kernel.
Just my $.02.
Thanks
reiser4 kernel 2.6.10
Small correction, suse and linspire use reiser 3
Suse and linspire
In Suse 9.2 there is an option to use reiser4, also Suse will switch to reiser4 soon. Same goes for Linspire. Expect reiser4 to be the default fs in the next major release (Suse 10)
InfiriT
Still an option and not in kernel
A year later, kernel 2.6.13 & 4 and reiser4 is not in the kernel...
Reiser4 has lost 1 year of more widespread use...
Maybe, if and only if Novell buys RedHat, reiser4 will be in 2.6.50... :-(
how do you determine its stability?
I would love to see it in the 2.6.10 kernel.
As for the subject of this post, I think that the lack of ability to clearly mark and compare differences in kernel and/or environment setup when you are testing make this determination more difficult. Sure we could all use scrap paper or perhaps even manually enter in comparisons on spreadsheets or html pages, but that is prone to error and negligence.
I say this because I have had "reiser4" problems for quite some time but can't be sure what the actual faulty part is. There are so many possible combinations of environments that you don't know if it is Reiser4's problem, some other component that only causes problems to manifest with Reiser4, or it not being Reiser4 at all.
I myself am more impressed by its claims and have seen nothing but slow downs and system instability on any of my systems. I will say that the block size handling alone has impressed me greatly as I have varied in file size and frequency of read/write.
Things I would like to try (or see results of):
- NFS exporting of part or all of Reiser4 partitions
- VMWare and other virtual machine sytems using Reiser4
- Large files with "simultaneous" read write on only portions of the file. (so that programs that make certain assumptions and optimize their io operations can be tested to ensure that the optimizations of Reiser4 don't inadvertantly cause less efficient file operations in these programs)
I look forward to seeing Reiser4 refined and really look forward to those modules :)
I'd like it
I've run my home box on Reiser4 for a while now. So far so good. But I can't really vouch for how stable it is. I am a very happy user of ReiserFS 3 though (on critical raid stuff as well), so if Hans Reiser says it's the next big thing I'm all ears.
However the objections raised on LKML were very legitimate. I have concerns over the race conditions. I hope Hans Reiser takes them seriously.
The big problem with it is pretty much contained in that last sentence. (That no one else really can.)
But keeping it out of even the mm tree would not make things better.
Reiser4 in main kernel tree?
I don't agree. Why? Look at my syslog:
Nov 18 02:21:07 localhost kernel: WARNING: Found but not happy: 2
Nov 18 02:21:07 localhost kernel: reiser4[pdflush(196)]: jnode_lock_parent_coord (fs/reiser4/flush.c:3093)[nikita-3178]:
System: Debian Sid, Kernel: Linux 2.6.9-mm1, Computer: Laptop Asus A3504NB with 2x256 ram.
For my luck I haven't lose any my data, but now I think we have to wait for a while...
Why not?
Is there anyone who can give a good reason why not giving users the *option* to use a filesystem that isn't that unstable without patching the kernel, is a bad idea?
hope it's in there
I want it in the kernel, but just trying to see the other side...how many other things could be in the kernel but aren't? I could think of numerous other patches that I wish were in the kernel that aren't (mppe for one). Obviously the line has to be drawn somewhere, but filesystem support is critical and I would guess Reiser has to be in the top three filesystems used on Linux. JFS has been in the kernel for quite a while now and I still don't consider it stable, even though it's not marked experimental. Reiser is important enough, and used enough that it should be there. It should have been there sooner!
Question: In JFS, file isn't directory?
Hi, i am using JFS, ReiserFS3. i felt JFS is more faster.
in ReiserFS4, file is directory and when hardlink it cause many errors, Right? then in JFS, file is just file?
sorry my ignorance..
--
If that was the only criteria
If that was the only criteria there would be a lot more shit in the stock kernel, Linux can't be a dumping ground for everyone's "brilliant" ideads. If that user wants it bad enough they can get the patches from the namesys site.
I use it on my main PC
I'd vote yes, but with reservations. If the kernel developers are waiting to see how many people are actually using reiser4 to dictate whether or not they should bother integrating it, then most certainly add me to the list. However, if they are waiting to resolve the VFS semantic issues before integrating the filesystem, then I would say not yet. I have run -wolk, -ck, and -cko kernels for a while in order to use reiser4 as my main filesystem. Having to run a non-mainstream kernel does not stop me from enjoying reiser4, it just stops me from reccommending others use it.
Reiser4
I believe Reiser4 FS is quite stable on my computer although I have backported it from -mm tree.
I think it can included in 2.6.10, obviously it can be marked as experimental.
To take all the bugs out, a larger audience is better.
Reiser is bad by design!
I did some research on filesystem design. NTFS, UFS, HFS+, REISER, ...
and i wondered, why the heck some of them need defragmentation, some of them obviously not. Defragmentation sucks.
Then i wondered, why postgresql slows down, needs vacuum, oracle on the other hand, does not need defragmentation, there is no slowdown noticeable. The answer: Oracle uses sparse databases, enough room between the records to do inserts, updates. Oracle has very efficient algorithms to make reuse of deleted records.
ext2/ext3 also seem to have intelligent strategies (bitmaps), to find out, where to place new data filling up gaps. Doing so, there is a self - defragmentation happening all the time. The only drawback is - you need more free space, some more as double the space, the biggest file consumes. Reiser had a problem - locks. During rebalancing the tree, linux locked up. Look at reiser code in the kernel. How many mutexes do you see, what does that mean ? Yes - kernel lockup during reindexing. Same technique like in MS SQL server - table write lock during reindexing.
NTFS - the same.
My personal conclusion is - all filesystems, additionally based on b-trees, need to be programmed multithreaded, a second thread continuously reindexing the inode tree, checkpointing from time to time ... locking sometimes ...
there are many parallels between database technique and filesystem technique. Look at PostgreSQL - has MVCC - every query only sees its own snapshot. (snapshot isolation) writes do not lock. ext3 is such a filesystem - look at "write back" - mode, "data = journal", ...some sort of mvcc ...
IMHO reiser is bad by design.
have fun !
This thread is about Reiser4,
This thread is about Reiser4, not Reiser3. As Reiser4 is build from scratch with a totally different design than Reiser3, it would be interesting to look at that instead. Your post isn't detailed enough to provide really interesting info, though some points you mention are valid.
Finding free space is easy, Reiser4's problem/feature is that it tries to pack all data very tight to save as much space as possible, with the idea that most data is read only anyway, which can cause problems when such files are expanded later and don't fit anymore in the place they are. Fragmentation in filesystems means that files aren't internally contiguous, not necessarily their placement on the harddisk, which is less important. Ext2/3 use 4K blocks, so that alone already gives some room for file expansion without needing to allocate a new block, Reiser4 can put multiple files in one 4K block.
Reiser3's problem was that it used not enough mutexes but instead simply used the big kernel lock, which is of course bad. I'm sure they didn't make the same mistake with Reiser4. Funny how you use PostgreSQL once as a bad example needing defragmentation, and later as a good example which does things right.
It's very impressive that Reiser3 with it's bad design was so much better than ext in Linux 2.4. Of course ext catched up with journalling and speed, but comparing the newer ext with the older Reiser3 and then daring to say that Reiser3 is bad, ignoring all the positive sides of it's design is rather arrogant.
reiser4 a must
Reiser4 is great. I've got over a terabyte on reiser3 and would like to move to reiser4 for files that don't require acls. One problem. In using mm kernels for awhile, its like a shot in the dark. Sometimes they work, sometimes they don't.