Slashdot Mirror
Reiser4 Filesystem Released
trixie_czech writes "It's finally arrived. Go to namesys for reasons to use reiser4 as a filesystem and benchmarks. Go here to download. Enjoy!" The Namesys homepage in its current stage reminds me of a cross between The Secret Guide to Computers and the GNU Manifesto -- which is to say, there is a lot to read here, not just a bullet-pointed feature list.
Will I be able to convert my exsisting ext3 fs to reiser4 fs withou having to reformat?
No, you will have to reformat. However, I recommend the upgrade; I've seen a number of studies showing that the performance of ext3 is awful compared to reiserfs. The only arguable advantage of ext3 is its compatibility with the baseline ext2.
Tubal-Cain smokes the white owl.
there is rfstool for reiserfs (afaik not v4)
and many for ext2/3
if OTOH, you are looking for a fully featured driver that can be used for production use, then i wouldn't count on it
Marge, get me your address book, 4 beers, and my conversation hat.
Yea, I would definitely recommend it. It's extremely speedy.
Possibly using convertfs, but I have no idea if it works or not.
This page seems to have more info about it.
Reasons why Reiser4 is great for you:
* Reiser4 is the fastest filesystem, and here are the benchmarks.
* Reiser4 is an atomic filesystem, which means that your filesystem operations either entirely occur, or they entirely don't, and they don't corrupt due to half occuring. We do this without significant performance losses, because we invented algorithms to do it without copying the data twice.
* Reiser4 uses dancing trees, which obsolete the balanced tree algorithms used in databases (see farther down). This makes Reiser4 more space efficient than other filesystems because we squish small files together rather than wasting space due to block alignment like they do. It also means that Reiser4 scales better than any other filesystem. Do you want a million files in a directory, and want to create them fast? No problem.
* Reiser4 is based on plugins, which means that it will attract many outside contributors, and you'll be able to upgrade to their innovations without reformatting your disk. If you like to code, you'll really like plugins....
* Reiser4 is architected for military grade security. You'll find it is easy to audit the code, and that assertions guard the entrance to every function.
V3 of reiserfs is used as the default filesystem for SuSE, Lindows, FTOSX and Gentoo. We don't touch the V3 code except to fix a bug, and as a result we don't get bug reports for the current mainstream kernel version. 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.
true that, also in ext3 there is no such thing as fast fsck after bad shutdown, i have tested myself and the improvement is little to none over ext2.
OTOH, reiserfs is very fast in this department
Marge, get me your address book, 4 beers, and my conversation hat.
Will we ever have a Windows port of ResierFS or any alternative filesystems?
I'm not sure about ReiserFS, but there is already a program -- Explore2fs -- which lets you mess around with Ext2 and Ext3 partitions from Windows. Why you would want to do that is beyond me, but there you go.
Of course, you may be talking about a native Windows implementation of Ext2/3 and/or ReiserFS. Which is a totally different kettle of fish...
Tubal-Cain smokes the white owl.
"* Reiser4 uses dancing trees, which obsolete the balanced tree algorithms used in databases (see farther down)"
that's what he meant.
oh, and whoever moderated offtopic didnt rtfa, either. damn, peeps.. what is wrong with this community these days?
pm
** "It's not my job to stand between the people talking to me, and the ones listening to me." -- Pego the Jerk
Well, Mr. Reiser Dude suggests tar in his posting to lkml which can also be viewed on kerneltrap.org.
In other words,
no.
yeah, that, and *stability*. reiserfs has a noteable history of people losing their data because of filesystem problems.
Not over the past couple of years -- the original corruption problems with reiserfs, although pretty severe, are well in the past now.
Tubal-Cain smokes the white owl.
ext3 has a functioning fsck, reiserfs does not.
I myself have never had any problems with reiserfsck -- what exactly is wrong with it?
Tubal-Cain smokes the white owl.
And yeah, you'd better believe it happens. The BSDs use a similar approach called SoftUpdates (basically odrered writes). If power craps out in the middle of a write, you will have corruption. The main advantage is that, because writes aren't scattered all over, you only lose the file(s) you were most recently working on. This focuses the damage, it doesn't reduce it at all.
AFAIK, with journalling, there shouldn't be *any* fsck after a bad shutdown - with the few times I've pulled out power cords, I've never seen an ext3 fscking.
Then it seems that reiser spends about a second doing a fast fsck every boot, whether is was shut down cleanly or not...
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
I'm not sure about ReiserFS, but there is already a program -- Explore2fs -- which lets you mess around with Ext2 and Ext3 partitions from Windows. Why you would want to do that is beyond me, but there you go.
I have a hard drive with Windows installed on it and a hard drive with Linux, and I use both OSes. Explore2fs is handy when I'm in Windows but I need to grab a file on my Linux drive.
Nope convertfs won't work... From the horses mouth:
To upgrade from reiserfs V3 to V4, use tar, or sponsor us to
write a convertfs.
The lkml posting is probably cached all kinds of places, but kerneltrap also reproduces it in full.
Then again, reiserfs v4 and v3 have nothing to do with each other (unlike ext2 and ext3 for instance), so there's no quick fix possible probably.
On the other hand - reiser4 is completely untested (compared to reiser v3 and jfs, xfs, ext2, heck even the wine-dll emulation layered ntfs writing driver...), so do yourself a favour and don't do anything quite so crazy as not just using it for a production machine but also trying to convert an existing system to it with 'smart' tricks... Give it a little while... or make a lot of backups...
Actually, v3 is NOT the default filesystem of Gentoo, Gentoo has no default filesystem, you pick what you want. They give the easy option of ext2/3 xfs and reiser
>MD5 has been proven to have collisions.
Statistically speaking you are more likely to get malaria in Arizona than experience a random MD5 collision.
Comment removed based on user account deletion
Um, yes, there is an advantage. That's what the journal is for (duh.)
It astounds me that your post was marked as "Informative," because it's downright wrong.
Now, if you're talking about fsck after a certain number of boots, or a full fsck for whatever reason, then no, there's no advantage over ext2. It's ext2 + improvements + journal, for the most part.
For my money, using ext3 without btree hash dirs is stupid nowadays. Go back and bench reiser vs. ext3. ext3 is usually still slower, but the gap is narrower nowadays.
Stating on Slashdot that I like cheese since 1997.
Err, the point of atomicity w/ journaling in a heirarchical system is that if you lose power during a write, it is data to which no parent i-node or directory points. The data being created or altered is written first, then its updated directory, and then its parent directory on up to the root. Or you have one journal level, where the file is written to journal and then the journal entry is copied over the original location. If power dies when the journal is being written, data is lost but the FS maintains integrity, or if the power goes during the copy, the journal exist. Atomicity means that a transaction either happens all the way or not at all, and Reiser4 does guarantee this. In-flight data can be lost so long as partially written data does not leave the system or some other API-level atomic transaction partially completed.
All hash functions have collisions; that's not the point... It's extremely unlikely for one to occur non-maliciously. The MD5 collision found was only found after some trivial mathematics done as a matter of principle by your network card just to spite you (okay, just kidding).
It's still perfectly fine to use MD5 to check the validity of your files for bit-errors. Then again, so is CRC32.
I do have a question to anyone more knowledgeable in MD5's weakness: although MD5 can now be spoofed , it's not clear to me from reading the news - is it only directly applicable to messages of a certain type/length or to all messages?
YAReg
http://yareg.akucom.de/index.html
works for me now.... I have to say I would much prefer a real driver, but beggers can't be choosers.
Karma Clown
Sure MD5 has been proving to have collisions, but that really isn't news. All hash algorithms have collisions simply because of the nature of what they do.
Suppose you've got a 1K file. There are 2^1K possible values that file can assume. If you map those 2^1K values to the 2^160 values a SHA1 hash can assume, you have an average of 2^944 1K files that collide on any give SHA1 hash.
What differentiates hash algorithms is their ability to prevent people from generate a text that matches a given hash. It is currently not possible to do this for either MD5 or SHA1. It has been speculated that MD5 is nearing the end of it's life in this regard though. I don't follow the field closely enough to weigh in on the matter, but I can tell you that the only thing that finding an actual md5 collision will do is demonstrate what was rather easily proved in the previous paragraph.
As far as verifying files is concerned, the cryptographic strength of the hash algorithm is irrelevant. Unless you suspect someone will be tampering with your results, use whatever algorithm you can find a useful tool for, be it md5, sha1, or even crc32.
When deciding which filesystem would be best for our first critical samba file servers, this post and other scattered rumors of unreliability scared us away from reiser3 for the time being:
u ly/msg00418.html
;)".
http://www.redhat.com/archives/fedora-list/2004-J
The date of the post caught my eye. The test was very recent. Ext3 won in this particular case, by a longshot, leading a Red Hat employee to respond "Your investigation proves that we default to the right mode
I haven't seen ext3 (ordered) lose in any reliability benchmarks versus jfs, xfs, or reiserfs, though it's hard to find many such benchmarks.
Actually they give the easy option of ext2/3, xfs, reiser, and jfs, and really it's no harder to use any other filesystem - though why would you want to? - that is fully supported by linux including support from some bootloader. Pick your filesystems, emerge the proper tools, make your filesystems, and keep going. Admittedly, they only document the steps for xfs, jfs, ext3, and reiser.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
In any case, if you're looking for a really nice filesystem, use XFS. It was developed by professionals (SGI), is fast and stable, and is now released as open source.
I suppose it's just a coincidence that the reiser benchmarks page doesn't compare it to XFS... or maybe they were too embarassed to show the results?
It's very disappointing that it took Linux all these years to get something as basic as a secure, encrypted way to store files. Even Windows has had FS encryption for a while.
The next release of Suse is going to be a doozy. KDE 3.3, Reiser 4.
"You're talking about porting a file system assuming the operating system is unaware of it. We can look at the source code and linux and find that answer out, but with windows it's more difficult to tell. Since Microsoft seems to only support FAT, FAT32, and NTFS, I'm sure that's built into the kernel for speed. So unless you're going to make something that emulates NTFS on top of reiser, I doubt it would ever work. And if you're going to do that, what's the point at the end of the day?"
;-)
Are you on crack or do you just not know that NT has always been about modular units. Cripes you have a monolithic kernel + modules kludge compared to a micro kernel. This idiocy/ignorance of basic comp sci hurts my head. Sorry. NTFS.sys and some loaders handle low level NTFS there is also a FAT/FAT32 driver and an NFS (thirdparty) filesystem driver. Back in the day even some Linux projects have used these files to mount NTFS partitions under Linux. Quit your idle Windows bashing knee jerk reactions. They just show how little you know about much of the computer landscape.
I myself would not be surprised if Reiser4 makes it to Microsoft's neck of the OS woods. Heck knows that that the NAMESYS webpage implies that they have made covert ports of past filesystems for other vendors and Microsoft has buckets of cash. Heck the processes are also well documented maybe even better documented than under Linux. To head off the knee jerk reaction of the few OS zealots that often piss on rational exposition here, yes you can sign an NDA and see just the file system hooks used by for instance Windows XP and get a nice binder documenting EVERYTHING you need to put your filesystem under Windows. So no there is nothing technically breaking a port and infact it might even be easier than writing a Linux module because the underlying OS of Windows NT has not changed as much as many believe.
Sorry to burst your bubble but not only is it possible but I think Namesys as a company should consider it. Heck I personally would pay for a better file system under NT/2K/XP/2K5. My employer would pay even more and MS heck the skies the limit. You would be either a fool or a zealot to not consider the deal. Afterall Linux could use Reiser5 and developement could always use a shot in the arm financially. If only to pay for pizza and beer
ping
It is now possible to generate a bitstream that matches a given MD5 hash. It's recent news too... :-).
Some postings can be found here, and google is your friend
--Eamon
The point isn't to guarantee that data was flushed to disk. But if it wasn't, you know it wasn't, and you have a previous copy of all the blocks in the transaction.
Atomicity isn't the same thing as synchronous writes, where the OS won't return from the write() call until the data has truly been flushed successfully to the disk controller (and with controllers which support it, to the platter itself). Atomicity says that a set of writes either happens completely, or not at all.
"man reiserfsck"
But ReiserFS doesn't need an "fsck" type program in normal circumstances. In power outages, etc., it's rock-solid. But for things like drive failures and the likes that tend to actually corrupt the data, then yes; EXT3 is the better choice. The reiserfsck program isn't intended to be run on the event of just any power outage or failed unmount, because those sorts of things don't tend to damage the filesystem.
I've been using ReiserFS 3 for years and I've really been happy with the results. The only times (once or twice) that I've had problems were when I had severe hardware malfunctions (due to failing mobo capacitors and a dying hard drive), and my own carelessness when trying to repair the bad data.
It rocks. Very, very fast. Whereas an:
would have taken about 20 seconds to run under reiser3, it takes about 5 seconds under reiser4. Very impressive.
I haven't had any stability issues with it. There were ( last time I checked ) 2 outstanding bugs - one nfs ( files on server with reiser4 ) bug, and one strange bug that made adn OpenOffice compile fail miserably. Bug (1) doesn't affect us, as our nfs server is running reiser3, and bug (2) I got around by creating a reiser3 partition, mounting
I just can't get over how fast it is.
I'll bite... Every hashing algorithm has collisions. Even SHA-1. It just has "less" collisions (infinities are strange) than MD5. XeeRz, Jason
THSsMCHshrtrTHN160chrs -- And I don't even like to SMS!
Over the past few days (ever since reiser4 was accepted into the mm kernels) I've been looking for a boot CD with reiser4progs 1.0. I want to try reiser4, but need a boot CD to format my new drives and mount my current partitions for copying.
l in ux/rip/
The only boot CD I was able to find was the (R)ecovery (I)s (P)ossible Linux rescue system:
http://www.tux.org/pub/people/kent-robotti/loop
It was released yesterday (22 Aug) and is still warm to the touch.
Stephen
I've successfully recovered a trashed array running ReiserFS after losing a CPU.
reiserfsck is there, and does work.
I've had more problems with the Ext filesystems than I care to mention, and we do not use Ext2 or Ext3 on any production machines that run Linux any more. Everything's ReiserFS v3, and once we start testing Reiser4, we'll move to that.
Ext3 was a hack for compatibility with Ext2. It serves its purpose, which is easy upgrades and backwards compatibility.
Its also true that by default after 6 months or 30 mounts an ext3 volume *will* perform a full fsck. This can be very painful if the volume is large enough/holds enough files that an fsck will take 24 hours plus (I've seen this several times)
Personally, I'm a fan of IBM's jfs. I had some early problems with it but they were real responsive to every issue I found while punishing it as an NFS volume in a test system.
You are in a maze of twisted little posts, all alike.
Reiser4 does not have such a problem, as it operates in data=ordered mode by default.
To get something done, a committee should consist of no more than three persons, two of them absent.
Thanks for the link. I actually wasn't aware of that particular attack. I'm still not sure that it means that's it's possible to generate a message with a given hash though. The attack presented talkes about generating two messages, M and M' such that M and M' have the same md5 hash. This is a potential problem, but it's still a step away from being able to generate a message that matches a particular hash.
I think you misunderstand, that's the beauty of it. Basically, Linux (and FreeBSD with GBDE) allows you to encrypt a device at the block level. Everything is written to the disk encrypted, including the file system itself and not just the data. This also allows you to abstract the device. It could be a big file sitting on an existing device or the device itself. It's very flexible.
Some of the other advantages of this are fairly important. Here's a few off the top of my head.
On the plus-side, filesystem level encryption lets you choose to encrypt on an as-needed basis (such as with NTFS), but the uses of this are minimal and questionable at best (what about swap, temporary files, and data that you forget to encrypt?)
I think you may have learned from my previous comments how you accomplish this. Hint: you don't encrypt at the filesystem layer.
Using the loopback device to encrypt data has been available for longer than NTFS has had encryption.
Why bother.
Joux has apparently proved (though no utilities are out yet) that you can:
Create a file with a pre-determined hash, and do so in a computationally feasible way (rumor has it: using _only_ 2^40 calculations...)
That is it. This means that at compute time you can MD5 a file and get its hash, and then create a garbage binary file with the same hash. In just 2^40 steps.
Big Damn Deal.
One thing that is interesting from a performance standpoint is that MD5 is great for keys (provided you don't have a rogue admin with a lot of time on their hands and heretofore unreleased MD5 hacking utilities), but MD5 is terrible for indices. Since MD5's are absolutely random there is as much chance as an MD5 being next to another as 2^128 key spaces away.
...But I digress. TREMBLE PUNY HUMANS!ONE DAY MY SPECIES WILL DESTROY YOU ALL!
Flesystems do not typically care about what the underlying device is (of course I'm not talking about "filesystems" devoting to the task of distributing the storage mechanism, such as NFS, AFS, CODA, and friends). Device access is handled at a "lower level" by drivers, I/O, etc. In otherwords, with Unix at least, a device capable of storing bits (including metadata about how to store that information, AKA a filesystem) is presented to the user and what's actually behind it is unimportant. It could be a hard disk, a chunk of physical RAM, a RAID array, a floppy disk, or a even another file sitting on an existing file system. To get a better idea for how all this works, read up on losetup which is available on pretty much any Linux system (assuming support for the loopback device is present in the kernel... which it should be).
Why bother.
Now that I think about it, the main problem would be with programs knowing that files can also be accessed as directories. tar would work fine provided that the readdir() system call (or whatever you'd use to get a directory's contents) returns both a file and a directory for each file.
"I think it would be a good idea" Gandhi, on Western Civilisation
When you image a device, you're not imaging data selectively, you're just getting whatever is there. In otherwords, you don't care what's on the disk, just that you are reading bits off of it sequentially.
Real world example: if I run dd if=/dev/hda it will (in addition to spewing bytes to stdout) start at the very first bit on the disk and continue reading the next after the next until the disk reports (specifically, the disk driver) that there are no more bits to be read. Whether or not that disk happens to be formatted with reiserfs or NTFS is irrelevant.
It is in this way that tools like dd or Ghost back-up and restore a disk exactly how you see it at the time of imaging.
(Cool tip: you don't need Ghost to take a disk image and store it across a network. All you need is dd, ssh and a target machine running the SSH daemon. Run: dd if=<the device to image> | ssh <user>@<target host> "cat > backup.img" . There are tweaks you can do to improve the performance of that (such as setting a larger block size on dd), but that is an exercise left to the reader.)
Why bother.
Doesn't Linux have any byte-by-byte comparison tools ? It seems like a total waste to compute MD5s to compare two local files...
Yes, it does -- diff. However, the point here is that the files aren't side-by-side; one is on the local machine, and the other on a remote server. Hence MD5.
Tubal-Cain smokes the white owl.
I suppose it's just a coincidence that the reiser benchmarks page doesn't compare it to XFS... or maybe they were too embarassed to show the results?
---
Please quit being a total twit. XFS has its' place, but for now, we are discussing ReiserFS. Just for the record, ReiserFS has been around for years, and does a great job with mixing loads of little to medium files. While XFS does an ok job, it really excells with the large files, in particular, very large sparse files.
I just wanted to add my two cents to this: We had done internal benchmarks at our company, and found XFS to be the fastest filesystem, and seemed to have a good track record with the community. (We didn't consider reiserfs because of its lack of bad block handling).
Either way, we converted ONE of our 2 Terabyte mount points to XFS. Whenever a file would be created on that mount point that exceeded 4G, bdflush would peg the cpu at 100%, commits to the disk would cease, and file system corruption ensured.
This was with kernel 2.4.23.. The problem was fixed in 2.4.25 (maybe 2.4.24, but we never tested that kernel). When we had this issue, and linked it to XFS (through another test system), we quickly migrated away from XFS, back to ext3.
We never had a problem like that was the ext's. We've lost data with both reiserfs and XFS. And if you grep the changelog for the kernels on XFS, you'll see tons of fixes for "deadlocks, race conditions, oopses", etc. These were all fixes AFTER 2.4.23..
Lesson: Stop playing with something that works, and be happy your servers serve. We never made it to testing JFS, and we probably won't. Ext3 might not be the fastest kid on the street, but it has been the most reliable for us.
-- If we don't stand up for our rights, now, there will be no right to stand up for them later.
Yes, it's true. No fast FSCK. But you wouldn't expect that from a true journal filing system anyway.
Just disable boot time FSCKs, and enable an FSCK at some interval you feel comfortable with. I've tried, with this configuration, to foul an EXT3 fs many many many times. Even as much as cold power off during a write operation, multiple times. It cleans up damaged innodes at boot time, recovers the journal, and continues booting happily. FSCK later, and you'll discover that not much has went awry, and the file system is still intact...
Try it out on a test box. It's truely the only way to go if you're using EXT3, in my opinion.
It may be possible to implement rollbacks of a large nature, but the first problem that will be encountered is the issue of filesystem locking to maintain consistancy. To do a fully atomic operation, all files that are going to be read or written must be locked against other modifications until after the transaction is complete. One thing this means is that all applications will have to support the locking semantics, otherwise there is a possibility of applications deadlocking. You don't want to be doing a large commit on /etc or /var for instance and have all sorts of deamons (or the kernel) deadlocking, crashing, or hanging because of lock issues. Performance is another problem, because locking files for a five minute install could hang up anything from "fortune" to "inetd". The other problem that can occur with transactional installers is the need to lock an arbitrary set of files after beginning an installation, and hence already having locked files. Deadlocks are even more prevalent in software that explicitly uses locking and fails to consider corner cases and how to back out of them. A sure-fire way to prevent these types of deadlocks is to only hold a single set of locked files at any given point in time, and only lock or unlock that set in its entirety. This can lead to over-locking, which leads to lots of busywaiting or timeout failures.
Versioning filesystems can give the advantage of consistent cross-sections of a filesystem at any point in time to individual applications, but applications still have to be specially designed to properly lock their own files and maintain internal consistancy with the application, especially with regards to using the appropriate version of a file. In the long term, object versioning will probably become the norm, since it allows large transactions without some of the bottlenecks and deadlock issues. But a general solution to the problem of locking and consistancy may be undecidable in theory anyway.
This is the single most important factor when it came to deciding what filesystem to run, namely, can reiserfs 4 be upgraded to new versions easily?
Yes; as I understand it, ReiserFS 4 is designed with a plug-in architecture, so that future improvements to the filesystem can be incorporated in a non-destructive manner. You can read more about this functionality in the summary of the new features in v.4.
Tubal-Cain smokes the white owl.
Journaled: The data is written to a temporary queue and then copied to the main storage. If the system dies while writing to the temporary queue then the main storage is unaffected; if the system dies while writing the queue to main storage then the system will notice when it reboots and will resume writing the queue to main storage.
PRO: Safer than non-journaled since you can never end up with half a buffer written to disk.
CON: Writes everything twice, causing delays. Very bad things could happen if data and associated metadata are in separate transactions and the system crashes between them.
Atomic: The file data is written to unallocated space on the disk. Once that has completed, the directory record is updated by writing a copy of that record to unallocated space. The directory's parent is then updated by writing *it* to a new region of the disk, and so on up the tree. Since each write doesn't take effect until the next has completed, any interruption results in complete reversion.
PRO: Safe. Faster than journaled since there is no double-posting.
CON: More complicated to impliment, I suppose. I would expect it to be slighly slower than journalled method when writing very small changes to existing files as journalled can optimise the writes in the queue whereas atomic has to finish what it started...
I don't know what kind of crack I was on, but I suspect it was decaf.
Too bad ReiserFS doesn't have a dump utility.
On reliability:u ly/msg00418.html
"After 3 or 4 power cycles, ReiserFS became corrupted to the point that the system would not boot up (the fsck failed and the bootup stopped there)." - http://www.redhat.com/archives/fedora-list/2004-J
On code maturity:r y/l-fs7/
"In contrast, ReiserFS' fsck is in its infancy..." - http://www-106.ibm.com/developerworks/linux/libra
Hans and co's attitude:
"For $25 you get an answer to any question we can answer with less than half an hour of working on it. fsck support sometimes takes more than half an hour" - http://www.namesys.com/support.html
diff(1) is primarily a text comparison tool, it tries to find the minimum difference between two text files and is very handy for creating e.g. patches to source code. For comparing arbitrary files though, you might want a tool that simply compares them byte-by-byte, and in that case you need to use cmp(1).
main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
Our atomicity does not provide isolation or rollback, it is only atomic in the sense of whether it survives a crash. That is, a reiser4 atomic set of operations will either all survive the crash or none of them will.
You can say that this is not really atomic, and by database traditions that is correct, but I believe we have implemented the aspect of atomicity that for sure should be implemented by the file system and not by the layers above.
Later we may support more isolation and rollback, but we started with allowing people to define a set of fs modifying operations that would either all be preserved across a crash or none of them would be preserved. I tried using the term "transcrash" instead of atom, but no one but me loved the term.
I must caution though that the API for defining an atomic set of filesystem operations is still being debugged. The core infrastructure is rock solid though, as it is what we use for atoms defined internal to the FS. We shipped as soon as our core code was rock solid, and plan to incrementally finish the other stuff over the coming year.
Explore2fs is nice, but if you want something better, take a look at ext2fsd. You can actually mount the partition(eg, G:\ or whatever) and have all your data usable by any windows app, rather than having to navigate inside explore2fs and copy it out.
It can read/write ext2 and readonly ext3, and hasnt messed my data up yet. if you're scared leave it in its default readonly mode and you should be fine.
google will find a link, its also linked to at the official ext2fs homepage on sourceforge.
Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx
And the answer is cheap! You should view the namesys.com support page:
$25 gets you an answer to a question about anything.
BTW, I'd like to know the answer, too. Could you go pay and ask the question, then come back and tell us all the answer?
Our response is definitely not so what. We might have told you that metadata journaling (what V3 uses) provides a level of service in which, like FFS and many other filesystems before it, if you crash during a write the write gets garbled.
Reiser4 is fully atomic though, and a write will either make it to disk entirely or not at all, with no data garbling. In other words, assuming that metadata journaling was what made you unhappy, we listened, but waited until a deep rewrite could allow us to fix it with no significant performance loss.
We are very happy that the use of wandering logs allowed us to make things atomic without losing any significant performance.
If we go for a week in -mm with no bug reports, I send it to Linus.
Our approach is to first get it to where nobody in the developer team using all known filesystem crashing scripts collected over 10 years can crash it, and then ask our mailing list to crash it, and only then ask real users to try it.
That said, if you have a mission critical server, be sensible, wait a bit.
It is in the -mm kernel, if it goes without a bug report for a week, we send it to Linus. I hav been surprised by the lack of bug reports after going into -mm. All we have is one apache 2 bug report that we cannot reproduce yet.
No, atomic is the only option for reiser4, there is no metadata journaling even as an option. So, it both goes faster and keeps your data safer. It is nice when experiments with algorithms work.... :)
Hans
Close. I will confess that I don't know *exactly* the precise definition of journalled -- I believe that roughly it's "write out each operation guaranteed to be atomic to the disk before that operation is committed"
Atomicity is not an alternative to journalling. Journalling is a mechanism often used to provide atomicity. Atomicity simply means that a change is either entirely committed to disk, or not committed to disk. There can be atomicity at various levels -- database transactions are also atomic, for instance, as is each operation on filesystem metadata in ext3 (which simply means that the filesystem metadata will not become corrupt on power loss).
An example of the difference between atomicity provided via journalling and atomicity provided without journalling -- if a filesystem recieved a write of 20 bytes to the end of a file, a write that fit within a block, it could simply read the contents of the existing block on the hard drive, and then write the modified block back, since block-level writes are guaranteed to be atomic on hard drives (assuming, of course, that the filesystem stores the associated length data in the block). This would not be journalled, because the change is never written to a separate location, but it *would* be atomic, since the filesystem is never in an inconsistent state -- either the change is written or it is not written.
There is also a mechanism similar to journalling (though different) called logging -- there are "log-structured filesystems". I am not familiar with the difference between journalling and logging. Just guessing from distributed systems knowledge, it's likely that logging means that every operation is written to a log in order, and that a filesystem's state can be reproduced by playing back the log.
May we never see th
In the test, the filesystem eventually failed to mount, and reiserfsck failed to fix it. Not very nice at all. Some lost data is one thing, a lost filesystem is quite another.
Finally! A year of moderation! Ready for 2019?
Oh, dear. Bad block handling is not needed on modern drives, all moderns drives have automatic remapping of failing blocks, and if you have a drive which actually has bad blocks which are visible to the OS you should not be storing any data on that drive.
Just to add a data point: I've also had very mixed experiences with XFS. I installed it and it seemed to be chugging along fine for ~1 year (just regular desktop machine, no particular I/O load to speak of) until suddenly the initial root mount showed an empty
HAND.
No, actually, waiting before deleting the old copy is not enough. You need to make sure that there are not two copies.
Think of classic banking example: credit savings and debit checking are a single atomic operation. You must ensure that you don't get the credit preserved and the debit lost by a crash.
The poster above you was right.
Alternatively use rsync's checksum feature! here are rsyncs best options to get an exact copy of your data: rsync -Ppogrtlhc *old location* *new loation* the options are permissions, progress, owners, groups, recursive, cant remember t, soft links, hard links, checksum. Not really for the overly paranoid but its always worked fine for me and i still have a functioning OS, just one with slightly better partitions!
How many computers are too many?
NTFS was usually between Reiserfs and Reiser4 in the benchmarks I've seen so far. Reiser4 being always the fastest by about 5-20%.
That was because reiserfs only hat a writeback journal then. The means that it could happen (very often) that the metadata was written before the actual data was and you would end up with random data in the files that were written just before the crash.
I know it because I had the same problems.
But the current 2.6 kernels have a lot of improvements. reiserfs now also has data=ordered and data=journal journalling modes (with ordered-data being the default now). This means that the actual data is written before the metadata is committed. I've never had those problems again.
And, BTW, it's hardly the fault of the filesystem that you lose some data if your system crashes.
The current reiserfs in 2.6 also has a lot of other improvements. A better block allocator, quota and ACL support. If you need those for 2.4, SUSE has had the patches in their kernels for some time now.
Yes ever hashing system has collisions, but really to check two files are the same which might have been corrupted naturally, use CRC, MD5 and other secure hashing alogrythums are just better against inteligent tampering. CRC's will catch an insanely large percentage of random data corruption and is faster than pretty much anything else, MD5's and SHA's are slower but much harder to fake.
The first UPSes that didn't have the charger running all the time appeared in the early 80s. They were actually called rapid standby systems at the time.
20 years later, there are no charger->battery->inverter systems left. They are very inefficient (meaning run hot) and are rather loud. People simply wouldn't use them if they were available.
A switchover type UPS will switch over to UPS power when the line power is bad. On a good one, you can say that 5% over is bad and make it switch. If it lasts more then the life of your battery, you're in trouble though.
Anyway, +/- 10% is NOTHING to your computer. They use switching power supplies. Switching power supplies adjust for input voltage. If you have an international power supply it can tolerate down to 90V and up to 240V with no ill effects. Even if you have a 120V only supply, it can still tolerate over 140V and down to 90V with no ill effects.
So, forget your +/- 10% stuff. It might matter on your stereo system, but not on your computer.
The problem with reiserfsck is that is will halt a boot of a RedHat system (waiting for someone to type "Yes" or "No" to run the fsck), that it is not named the same as the rest of the fsck tools (you can't use "fsck -t reiserfs"), and the output is completely different from the rest of the fsck tools.
Why can't all the filesystem designers rename, or provide links on install, their fs utils to match the standard fs utils??
2^8K possible values, unless you meant a 1Kbit file.
The READ.ME clearly states which version of Linux is required. It's some funky 2.6.8-rc2-mmsomething. I for one wait for Reiser4's inclusion in the vanilla tree. Meanwhile I'm testing XFS and JFS too see how they stack up against Reiser3 (which I've used without problems since early 2001).
Escher was the first MC and Giger invented the HR department.