Slashdot Mirror
Linux Gains Lossless File System
Anonymous Coward writes "An R&D affiliate of the world's largest telephone company has achieved a stable release of a new Linux file system said to improve reliability over conventional Linux file systems, and offer performance advantages over Solaris's UFS file system. NILFS 1.0 (new implementation of a log-structured file system) is available now from NTT Labs (Nippon Telegraph and Telephone's Cyber Space Laboratories)."
" When the system reboots, the journal notes that the write did not complete, and any partial data writes are lost. "
Isn't this similar to NTFS's journaling file system?
There is a "cleaner" that is on the TODO list.
Of course, you can delete files and re-use the space. But the performance slows down greatly once you start filling in "holes" left in the log after wrapping to the end of the allocated area. (A similar situation to database where you might want to compact, vacuum, condense, etc. a table).
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
If they are serious about a filesystem, it has to be bundled with the linux distros every release. Take Reiser and JFS for example, some distros have it, some don't. Not every release of the same distro has it, what a mess. Only two have stayed permanently EXT2, EXT3. Everything else is trendy.
Aside from gasoline and water, data is the most valuable thing in the world.
.tiff format) along with full-quality movies and all the games I've ever played back to Duke Nukem on 80x386 on a RAID array that's grown to nearly 2 terabytes.
:) Same for HDDs
Walmart's most prized possesion is their billion-billion-billion transaction customer sales database. They use it to find things like, among other things, men tend to buy beer and diapers at the time.
With disks costing $1.00/GB or less these days, many people including myself simply DON'T delete data anymore. I keep all my original digital photos (in
So yes, for many people, disk space is just something you keep adding to, like you'd move from a coupe to a sedan when you have kids and when you have that 6th kid you move to a minivan and if you happen to have 2 more, you get a cargo van when #8 comes along
If you "get" pointers add me as a friend (116)!
Ever since journaling file systems became available I just started turning the power off to my computers (via a power strip) rather than going through the shutdown command.
That's a very bad idea. Normally, journaling file systems only guarantee that the file/directory structure remains intact. It does not necessarily guarantee that the data in the files hit the disk. Also, your disk will probably have a cache that is lost when you remove power. Whatever is in the cache will also be lost.
So your file system may be intact, but your practices will probably destroy data.
)9TSS
I've had an idea kicking around for a while now... "HDFS / Home-Dir File System" ... I want a (s)low-performance, bloated, version controlled, roll-back featured, viewcvs.cgi enabled file system for my /home/rames (or at least /home/rames/documents).
With FUSE it might even be possible for mere mortals like me.
Basically, I very rarely push more around more than 100-200kb at a time of "my stuff" unless it's big OGG's or tgz's, etc. Mostly source files, documents, resume's, etc. In that case, I want to be able to go historical to any saved revision *at the file-system level*, kindof like "always on cvs / svn / (git?)" for certain directories. Then when I accidently nuke files or make mistakes or whatever, I can drag a slider in a GUI and "roll-back" my filesystem to a certain point in time and bring that saved state into the present.
Performance is not an issue (at first), as I'm OK if my files take 3 seconds to save in vim or OpenOffice instead of 0.5 seconds. Space is not an issue because I don't generally revise Large(tm) files (and it would be pretty straightforward to have a MaxLimit size for any particular file). Maintenance would also be pretty straighforward: crontab "@daily dump revisions > 1 month". Include some special logic for "if a file is changing a lot, only snapshot versions every 5-10 minutes" and you could even handle some of the larger stuff like images without too much work.
Having done quite a bit of reading of KernelTraffic (Hi Zack) and recently about GIT, maybe it's time to dust off some python and C and see what happens...
--Robert
Here's a little (simplified) tutorial on what happens when you a program writes a file to disk:
I am TheRaven on Soylent News
Here is a sampling of the known bugs
The system might hang under heavy load.
Are you intolerant of intolerant people?
If you have a licensed copy of the OS you can get source. Or at least, you used to be able to - many years ago when I was considered a VMS expert (something I certainly am not now) I used to look stuff up in the fiche; most of the stuff I was referencing was written in BLISS, I think.
As I recall, RMS is an indexed file management system. I wrote a molluscan taxonomy database system that used it in the 80s... but I usually encapsulate all OS-specific stuff in subroutines, so somebody has probably ported it to a cheaper database by now.
Assuming that it does actually do the trick, it might be even better than wiping a single file. Since the whole drive would be filled with random data, there wouldn't be any conspicuous wiped blocks sitting in the middle of an otherwise normal looking filesystem.
Dewey, what part of this looks like authorities should be involved?
I've always wondered if it would be worthwhile to have a version control style filesystem. Basically, a built-in subversion or CVS-type backend that operates without your knowledge until you need to roll something back. Of course you'd need to manage space usage, but with 1TB storage capacities within reach of the home user perhaps it's less of an issue? I think losing data is quite a bit more expensive than storage these days. :-)
But, on a log based file system, writing is (intended to be) "fast enough". The problem with writing to a normal file system is mechanical issues; moving the head, waiting for rotation, etc. The (unobtainable in the limit) goal of a log based file system is to be able to start writing /immediately/ with the current head position; therefore, latency is (or approaches) zero and bandwidth is limited by disk bandwidth (which is, in practice, not the limiting point for most small writes).
I've had this sig for three days.