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?
Will we ever have a Windows port of ResierFS or any alternative filesystems?
... but can they tango?
I only have one question (And I obviously have not researched an answer...):
Is there an easy and non-destructive way for me to migrate my ReiserFS version 3 to a version 4 Filesystem?
--Pathway
but will it save Namesys from a slashdotting?
Seriously.... their server admins must be FSCKing angry.
-- If you try to fail and succeed, which have you done? - Uli's moose
Yea, I would definitely recommend it. It's extremely speedy.
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.
IT'S ABOUT FREAKING TIME!!!!!
I did an informal comparisson of this fs against several others for one of my classes, and my results had it winning _hands down_.
But on a more serious note, I hope this release is stable. From lurking on their mailing list, it seems that it hasn't been too long since they were in bug-squashing mode.
...to use it for a while. I'm sure it's been tested very extensively, but there are always bugs initially in any major release like this. I'm sure nobody running a server will touch this for a while even with the benchmarks.
I'm not trying to spread FUD on reiser at all, I run reiser 3 and I've never had any problems. I'm just raising the question of how long does it take until people will put it in production servers and their main desktops?
Anyone who maintains servers care to shed some light on this?
There doesn't seem to be a Windows version of Reiser on that li....
Oh...
"...Well, there's egg and bacon; egg sausage and bacon; egg and spam; egg bacon and spam; egg bacon sausage and spam..."
"The Namesys homepage in its current stage is reminds me of a cross between The Secret Guide to Computers and the GNU Manifesto " Yea, i see "This page cannot be found" on alot of websites
I remember reading something a while back about how ReiserFS would occasionally barf and corrupt data... And that the Dev response was something to the effect of 'so what?'.
How stable in this new version in terms of data loss? Is this something that's optimized to run on a RAID array--with, say mirroring--that gets it's speed from dangerous shortcuts that are only acceptable in a non-single-disk environment?
IF you can get to the site, you'll find this juicy reference at the end:
[NTFS]
"Inside the Windows NT File System" the book is written by Helen Custer, NTFS is architected by Tom Miller with contributions by Gary Kimura, Brian Andrew, and David Goebel, Microsoft Press, 1994, an easy to read little book, they fundamentally disagree with me on adding serialization of I/O not requested by the application programmer, and I note that the performance penalty they pay for their decision is high, especially compared with ext2fs. Their FS design is perhaps optimal for floppies and other hardware eject media beyond OS control. A less serialized higher performance log structured architecture is described in [Rosenblum and Ousterhout]. That said, Microsoft is to be commended for recognizing the importance of attempting to optimize for small files, and leading the OS designer effort to integrate small objects into the file name space. This book is notable for not referencing the work of persons not working for Microsoft, or providing any form of proper attribution to previous authors such as [Rosenblum and Ousterhout]. Though perhaps they really didn't read any of the literature and it explains why theirs is the worst performing filesystem in the industry....
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.
Somebody post a bulleted list of featuress already! I'm a busy man, I don't have time to read anything longer than two and a half pages of double-spaced 12pt Courier, and that's only for the executive summary of my encyclopedia A-L anyways.
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
Now when will we see it in the vanilla kernel?
Damn ext3...
Oh well, what the hell...
Comment removed based on user account deletion
I'm going to stick w/ Emacs for my filesystem thank you.
ReiserFS is great, and this seems like a tasteful way of implementing some of the complex things people seem to want to do with file systems.
But I would feel uncomfortable relying on any of these features right now because any software that does would fail with any other file system. ReiserFS is free software, but you still end up needing to run software on other file systems in many cases.
I think for these features to become widely adopted, we need some kind of library-based emulation, something that uses ReiserFS if it runs on it and otherwise emulates ReiserFS features like files-as-directories in user mode on top of existing file systems (by using funny file names, etc., similar to UMSDOS).
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.
Yes, that certainly comes across more like a manifesto than a detailed exposition of software architecture. I have to admit, reading through it, my KOOK Alert was almost reaching critical stages ... if they only included SOME ALL CAPS SECTIONS as well as a reference to Einstein, who was on the brink of making a similar discovery, but was forced to suppress it DUE TO GOVERNMENT INTERVENTION, then the KOOK alarms would be blaring and I'd've discounted the entire thing.
... they never trusted me at the academy ... but they'll learn the hard way ... mwuahaha, er ... ha.
Now, all I'm interested in doing is exploring the potential of doing everything in the "manifesto" literary style. My next letter to the editor? Manifesto. My thank-you note to grandma? Manifesto. My resume? Manifesto. My next Slashdot posting? Manifesto.
Oh yes
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.'"
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.
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.
I have to wonder. ReiserFS does really nice with all the hard-work partitions I have over here, and I'm more than willing to convert (yes, using tar if I must), risking crashes and data losses.
But what crashes/corruptions are we talking about? Will I lose my entire filesystem? Will files randomly disappear? Will it install Windows on my Linux box? (Lords no!)
How tested was this 1.0 release? I have to assume it was "thoroughly but not fully" tested, am I right? After all, why release a 1.0 if you're not ready to "promise" at least basic stability to normal users?
Lex
1)
Ok, so thats the standard response, but the main benefits will be stuff like: encryption plugins (so easy per directory encryption).. Finally maybe we'll have fully encrypted home directories easily. and stuff like the winFS system integrated into the filesystem possibly. its also 2X faster then reiserfs, and 4X faster then NTFS The big issue though is that until freebsd gets these benefits, apps aren't likely to get these capabilities :(
so maybe someone should work on porting this, then maybe theres a good chance these technologies will be used extensively..
Well, the Reiser4 plugin infrastructure allows for more functionality to be added to the filesystem. Depending on the plugins created, the processes accessing this filesystem may need to know about them. E.g. GNU tar is incapable of preserving extended attributes and ACLs when copying data. Or look at the NTFS streams feature. This kind of thing needs at least some support in userspace, or else it can't be accessed.
It will very much be possible for people to write code that needs to run on Reiser4 in order to work properly. It will be interesting to see if this happens, and if so, how widely adopted it becomes. I think there's a lot of potential here, but I understand how people might be reluctant...
noah
Unless you have *synchronous* atomic commits, you'll still lose data on power loss. And while I think a synchronous atomic filesystem would appeal to a bank, most end users want something a little quicker than frozen molasses.
Don't blame me, I didn't vote for either of them!
How large (and long) can Reiser atomic transactions be?
Can I write an installation program which creates, replaces, moves, and deletes many files and directories, and have it all be under one transaction with a single commit at the end? Do other 'sessions' not see the transaction until it is complete? Are sessions based on processes or threads or something else?
That would be pretty amazing, to be able to roll back large sets of changes in case of an error. I know that database rollbacks can take large amounts of time (they optimize for the commit, which makes perfect sense) but nonetheless having rollback support in applications would be sensational.
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.
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
Write on the blackboard 10^10000000 times:
"EVERY computer needs an uninterruptible power supply. EVERY one."
There are so many problems of which you might not be aware, aside from those requiring you to run fsck afterwards, which are solved by a good u.p.s. that you'd be penny-wise, pound-foolish for not putting a u.p.s. on every machine in sight.
My clients think that I can walk on water simply because I eliminated a large share of unexplainable wierdnesses from their machines by installing an inexpensive u.p.s. on every single one.
Solid, clean power is very important to a stable computing system. I cannot stress this enough.
slashdot: A failed experiment.
Reiser? Stable? Now those are two words that don't belong in the same sentence.
In dealing with ext3, JFS, and XFS, Reiser has proved the most annoying because first, I have to do a full fsck on it most frequently, and second, a quarter of the time it is the root fs and needs rebuild-tree, which is annoying as freaking hell because you can't even have it mounted read-only. XFS I've had issues with two, but never having to completely umount to fsck. JFS has issues where it's journalling doesn't seem to catch something and it later in the middle of operating, figures out it is inconsistant and remounts read-only for fsck, which is also highly annoying. In all cases, get ready to dig through lost+found and figure out what filenames those inodes used to be associated with.
If you seek stablity (which is extremely key for filesystems), the only way I've found to work is ext3. It is a real slug (a *real* slug), but I would trust it much more readily than any other fs.
XML is like violence. If it doesn't solve the problem, use more.
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.
This looks very cool.
.reiser_meta folder in each directory to store the corresponding file directories? Or is there another way?
Using files are both files and directories is really nice - throw ACLs, metadata, whatever in a directory the same name as the file: access it as a file and it is the file, access it as a directory and it provides access to the metadata. It doesn't break things. Well, not much. As mentioned, this will break things like tar a bit. But the VFS has managed to deal with resource forks from HFS, albeit in a slightly ugly fashion. This is a little nicer, and perhaps with time will be the framework for slowly abandoning outdated filesystem concepts.
How would you mofidy tar to deal with this? Add a
"I think it would be a good idea" Gandhi, on Western Civilisation
I'm hanging out for a SQL pluging. Being able to "SELECT filename FROM filesystem WHERE size > 1000000" would be fantatstic (note very basic example). Not to mention meta data plugins that can index your media files and store that data in the filesystem (again with SQL access)
Normal people worry me!
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.
Usually, unstable Reiser filesystems point towards misconfigured or faulty hardware.
I maintain ReiserFS v3 filesystems on terabyte arrays, on database servers, and on our machines that go out to client sites. ReiserFS has performed very well for my company. We are a 24/7/365 shop. Downtime isn't in our vocabulary.
With so many filesystems around, it is strange that nobody is working on interopability. Till today no filesystem exists which works well both in windows and linux.
1. FAT - comes close but does not support very large paritions and files larger than 4GB
2. NTFS - Poor write support in linux
3. EXT2/3 - Writing hardly works in windows and does not support large files.
4. ResierFS/XFS - Have limited support in windows.
Any multi-OS file system out there?
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.
I have to take exception to this, as according to everything I know, this is a bit deceptive. As you would normally want to use a journaling
filesystem on very large discs (whether this be regular hard drives, which is bad enough, but can get very large when dealing with raid arrays, for
instance). 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? In the past, the only way to upgrade rieiserfs was to reformat the device. This is a point that I don't think people pay enough
attention to, especially in production enviroments. Say I have a 500 Gig raid array. I use reiserfs, (which is an excellent filesystem) and it is
later discovered to have a security flaw or a bug that causes data corruption. In order to upgrade to a new version of reiserfs, you have to
reformat the entire array. With ext3, you unmount the device, mount it as ext2, unmount it and remount it as ext3. Done. This is hugely important.
I am completely uninterested in having to maintain a 1Tb of drive space, in order to upgrade a 500G array.
Well, that wouldn't happen, you say? It did. Google
Also, I do seem to remember some problems running LVM and NFS on reiserfs as well, but I am willing to be corrected.
SealBeater
P.S. I am only really interested in knowing if I can upgrade a reiserfs filesystem without having to reformat.
-- Its survival of the fittest...and we got the fucking guns!!!
If you don't want FAT16, FAT32, NTFS (4 or 5), or the OS2 thingy, aren't you out of luck? How would you even install it? Much less mount it, format it, or take advantage of it.
I am not being facetious either, I really want to know
...But I digress. TREMBLE PUNY HUMANS!ONE DAY MY SPECIES WILL DESTROY YOU ALL!
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...
There are two kinds of people, when it comes to the original VW Beetle: Those who love them, and those who hate them.
People who do not fall in one of the above two categories have never really used or owned an original VW Beetle.
It seems filesystems are the same way. I'm a long-term Ext2/3 user and have never had any particular issue with it. For the medium-power stuff I work with, it does fine. The filesystem on my laptop has been ext2/3 for almost 5 years now, I still have email, documents, etc. from 5 years ago on it. (It's been copied a few times - it originated on an AMD K6 system, now it's on a Dell Centrino Laptop)
So, I guess I'm in the "Ext3 is all good" camp.
Reading these posts, there are those who love Reiser, and those who hate it. Those in the middle haven't apparently used it.
I've found Ext3 to be slow when you have more than about 5000 files in a directory. If I had a specific need for that, I'd consider Reiser if my particular distro (RedHat migrating to Debian) supported it "out of the box".
Other than that, why bother? I've delivered millions upon millions of email messages and many millions of website hits on servers running Ext3.
So, for me, what filesystem I use is sort of like what tires I use on the car. I might care slightly when installing, but otherwise I wouldn't give even a rat's ass.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
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
Now I have added scripts to my system that give me all the point and shoot functionality of pgpdisk in windows. All it took was a bit of time to learn the tools (mountloop, mount, umount, etc) and a hack of a shell script I found online and now opening an encrypted filesystem is as easy as clicking it, typing the pass, and pressing enter.
What makes the present system great is its level of abstraction. Having a "thing" one can move around to ANY media without having to create new tools every time is a thing of beauty. It takes a tweaky (and now proprietary) add-on to do this in windows - sticking all the encryption in the fs itself would just be a step back to doing things the Redmond way.
Good to hear the Linux filesystem envelope is being pushed further. The illustrations make me wonder if LSD had anything to do with Reiser4, but... whatever helps, I suppose.
if you can intentionally cause collisions by modifying messages appropriately. Then the hash becomes useless for verifying message integrity (because someone could have modified the message while keeping the hash identical).
HAND.
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
The gentoo guys have not complained about my characterization, if they do in an email I will change it. As the other poster said, gentoo seems to prefer reiserfs in what they write and say.
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
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.
There are also some severe disadvantages to block-level encryption -- from a user standpoint, WinNT-style filesystem-level encryption is generally preferable. Among other things:
* Filesystem-level encryption can outperform block-level encryption.
* It's easy for a Windows NTFS user to "start encrypting something" -- they right-click a directory and check a box. Linux requires a new mounted filesystem running through a new loopback device. Since this isn't doable at the user level in any distro that I'm aware of, it pretty much means that each user doesn't have their private files encrypted separately.
* Choosing as-needed performance is not trivial. I currently maintain individual files encrypted with GPG. I don't want to have to have my P2P software making my kernel blow cycles constantly and unnecesarily encrypting and decrypting software.
* Unless I'm doing something really grotty, like putting a filesystem on block-level encryption on an LVM virtual volume, if I'm using block-level encryption, I'm forced to choose how much space to allocate to each encrypted area -- how much to put towards my ~/.private directory, how much to put in my ~/main/notes/passwords directory, and so forth. If I'm using filesystem-level encryption, I'm taking available space from a shared pool.
* While not strictly a block-level vs filesystem-level encryption issue, no major distro that I'm aware of provides a nice interface for setting up encrypted directories (well, mount points with block-level encryption) and home directories, with a user's login password used to decrypt keys used to access the encrypted filesystems. Windows is significantly more user-friendly (including providing the option of administrative key recovery) here.
The block-level approach is ideologically clean and modular, but has serious drawbacks. It cannot replace filesystem-level encryption.
May we never see th
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.
One of the things I still miss most under Linux are a proper trashcan/undelete (at filesystem level, not at GUI level that doesn't help on the shell) or even better a full blown 'undo' operation on the filesystem. Even MSDOS provided a very basic undelete operation and I can't really believe that we are still without it on Linux.
Does ReiserFSv4 provide stuff like that? Or in case it don't, are the 'Plugins' that it supports
powerfull enough for that and are there maybe already plugins awailable that add an undelete/undo? Better yet would of course be a fullblown versioned filesystem, how about that, is that doable with ReiserFSv4 plugins?
And how do the plugins relate to for example GNU Hurds translators or LUFS? Do they act at a similar level, or are they completly different?
- I get to upgrade my filesystem so that I don't get to downgrade my kernel should I run into trouble.
- Whenever something doesn't work right, (which never happened to me on Ext2), Hans Reiser tells me that "it's fixed in the newest version", and I get to upgrade my kernel and on-disk-format without the possiblity to back out.
- When things DO go wrong, (which never happend to me on ext2/ext3), it seems I need to tell reiserfsck which sub-version of the filesystem is on my disk (Hans knows that very well on his disks, but I just use filesystems to store my files). Otherwise reiser-fsck may make a bigger mess than it started with.
- When reiser-fsck is neccesary, it often requires a "rebuild-tree", which is time-consuming.
- My filesystem was "suspect". So I start reiserfsck. It apparently does nothing, as it's done in 2 seconds (which is unlikely on a 640Gb partition) When reiser-fsck --rebuild-tree is started it informs me that it's going to take some 5 hours to complete. As I didn't have that time, I interrupt it. Filesystem gone. Apparently the first thing it does is invalidate the old structures. Now instead of "suspect" I don't have a filesystem at all, and have to sit out the 5 hours for which I don't have the time....
- I sometimes have a disk-image of a different filesystem on my disk in a file. Hans Reiser tells me that a rebuild-tree would link the files inside the image into my filesytem! Fixed in newest version. Phew.
Too many (serious) problems, that I'm not ever going to try Reiserfs again. Sorry.> The cause was a hardware problem, true, but fs should not be a toast because of it.
;-)
When you develop software that is immune to hardware failure, be sure to let us all know
Ran a huge article on Reiser4 a while ago. (Around 2 issues ago)
They said it was blazingly fast, but had problems, that the performance went down the drain once the processor did something not reiserfs related, thus IO is a higher burden on the processor, due to the tree structure they use.
The other problem is fragmentation, which should be resolved by a defrag daemon/tool running in the background, which was not available back then.
So my question, have those two problems been resolved already?
You saw Anonymous Coward at OLS? SWEET! That dude posts like MAD around here!
-l
Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
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.
So with a plugin, could you make a Reiser4 fs work like VMS' file system (i.e. foo.c;1, foo.c;2, etc.)? To me this is the holy grail of file systems...built in versioning by the file system itself, not a 3rd-party app like CVS.
I was able to use reisersfsck to repair a partition resize that had gone wrong. I was pretty impressed -- only three files lost out of 20,000 (and fortunately they weren't important files!)
So I'd say it works pretty well.
Ever notice that all the reports of ReiserFS corruption seem to be from RedHat users?
This should tell you something.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
I have a 120gb drive and only around 20gb real data, maybe 10gb for the OS itself, add a another 30gb random junk to that and I still have 60gb of my HD virtually completly unused. Even if tempfiles are not handled special it will take basically forever before my filesystem fills up, its really a non-issue these days.
Beside that, I am taking about an 'intelligent' trashcan, not these "Your trashcan is full, please empty manually" ones. If the HD fills up, the trashcan should of course free itself and overwrite old stuff, possibly with custom threshold and such, no problem there, since in most cases you will find the error you did that lead to file loss relativly quickly anyway.
### Even the MSDOS undelete only worked provided that you didn't overwrite the data with something else (if I recall correctly).
Yes, it did and its undelete weren't much powerfull or anything, but it was there and it worked already quite fine on old 386er with lausy 200mb harddrives, hardware improved quite a bit since then, undelete features however didn't for no obvious reason.
### In the end I think we would be better served by a smarter 'rm' and a better GUI trash can (not the cheap hack the KDE team came up with).
Such stuff will NEVER be enough, I don't actually 'rm' my files, in most cases I overwrite them with 'convert', via piping or whatever. And thats exactly the reason why I want undelete at filesystem level, since the filesystem can track all these without problems, something implemented at the GUI level however can only ever track a very small fraction of excidental deletes or overwrites, if at all.
The hardware to handle a versioned filesystem without problems has at least existed for a decade, its really just the software that still hasn't improved, neither on Linux nor on Windows or MacOS.
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.