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)."

Stable?

[theJML]

I like how they say it's reached a stable release but if you look at the known bugs on the Project Home Page http://www.nilfs.org/ [nilfs.org] You'll see that:

The system might hang under heavy load.

The system hangs on a disk full condition.
Aren't those kind of important to saying that something is stable?

Here's an overview for lazy people like me

[Work Account]

NILFS is a log-structured file system developed for the Linux kernel 2.6. NILFS is an abbreviation of the New Implementation of a Log-structured File System. A log-structured file system has the characteristic that all file system data including metadata is written in a log-like format. Data is never overwritten, only appended in this file system. This greatly improves performance because there is little overhead regarding disk seeks. NILFS also has the following specific features:

        * Slick snapshots.
        * B-tree based file and inode management.
        * Immediate recovery after system crash.
        * 64-bit data structures; support many files, large files and disks.
        * Loadable kernel module; no recompilation of the kernel is required.

actual info about the fs

[cowens]

http://www.nilfs.org/ [nilfs.org]

Re:New Improved?

[cowens]

On its project page LFS is listed as a related project.

Re:Horrible headline

[TheRaven64]

The title was written by a numpty. This is a log-structured filesystem. These systems have been around for ages. NetBSD has LFS (originally from 4.4BSD), and I believe Minix also had some form of log-structured filesystem.

A log-structured filesystem doesn't modify existing files. Every time you write to the disk, you simply append some deltas. This gives very good write performance, but poor read performance (since almost all files will be fragmented, and the entire log for that file must be replayed to determine the current state of the file). To help alleviate this, most undergo a vacuuming process[1], whereby the log is replayed, and a set of contiguous files is written. This also frees space - something that is not normally done since deleting a file is done simply by writing something at the end of the log saying it was deleted. In addition to the good write performance, log-structured filesystems also have an intrinsic undo facility - you can always revert to an earlier disk state, up until the last time the drive was vacuumed.

The snapshot facility is not particularly impressive. It's a feature intrinsic to log-structured filesystems, and also available in other filesystems (such as UFS2 on FreeBSD and XFS on Linux). The performance advantage claims must be taken with a grain of salt - write performance for log-structured filesystems is always close to the theoretical maximum of the disk, but this is at the expense of some disk space, and read speed (although LFS did beat UFS in several tests on NetBSD).

[1] This is usually done in the background when there is little or no disk activity.

Re:Shutdown versus power off

[Kiashien]

...that's mean to the hard drive. That can cause serious damage- and not because data hasn't been written yet...

When you cut the power to a HD, the head stops wherever it is- sometimes even settling on the drive itself. This causes severe wear and tear, and sometimes damage. It's one of the many reasons why people are told always leaving your computer on is less damaging than turning it off.

The difference between cutting power and a proper shut down, is that during a proper shut down, the OS ensures A) everything is written (which you may not care about) and B) that the drive heads are in a locked, safe(ish) position.

You may not care about A, but you really should care about B.

Re:Bloat?

[ivan256]

I wrote a (unfortunatly, closed source) filesystem that was remarkably similar to this once. Generally these types of filesystems are used when you're constantly writing new data. You're going to be eating the space anyway, but you want the reliability of syncronous writes with the performance of asyncronous cached writes. Reading from these filesystems is incredibly slow in comparison.

The version I wrote took advantage of the client's bursty IO pattern and used the slow periods to offload the data to an ext2 filesystem on a seperate disk. Hopefully your system memory was large enough that the offload to the secondary filesystem happened without any disk reads. Once that was done, the older sections of log could be re-used.... But only once the disk filled up and wrapped back to the beginning, because you want to keep your writes (essentially... There's other timing tricks you can play to get more speed) sequential.

There's been lots of research done on this method of write structuring. Look for papers on the "TRAIL [sunysb.edu]" project (also closed source), for example.

Re:Bloat?

[b100dian]

Actually this is a journal filesystem, as opposed to journalized. That is, each file is a journal.

Re:Shutdown versus power off

[dlamming]

Don't be ridiculous. Every drive in the last 5 years, maybe the last 10, is able to park the head safely even in the event of your pulling the plug on the drive itself. It's got some springy/inductory dealie that pulls the head to a safe landing area.

That doesn't mean that you won't lose data that hasn't been written yet, of course. :)

Re:There's no replacement for ext3fs yet for me...

[m50d]

Reiser3: How's the quota support, still have to patch kernel everytime? Plus it doesn't have ACL.

It does have ACL, and quota support is fine at least in gentoo kernels (can't check a vanilla one atm)

Re:The dreaded question

[thc69]

Will there be a Windows Driver? If there isn't, this has no chance on taking off.

Yes, that's why I only use FAT filesystems on my Linux server.

You're probably joking, but fyi... There's at least one driver for mounting ext2 fs in windows: ext2fsd. If you don't need to mount it, explore2fs works well too.

Re:New Improved?

[Feyr]

the why is dependent on your application,

for common servers, or day-to-day use. it isn't

but notice how this was developped by a telecom company? a log structured filesystem is perfect or even required, due to speed and integrity constraints (depending on the size of the network), when you're dealing with billing and monitoring data on a telecom network. you want something that's simple and extremely resistant to failures. a complete system crash (which never happen, short of nuking the box) should not result in any data loss, or the extreme minimum, and you should be able to recreate that data from somewhere else (eg, the other endpoint in a telephone network).

a log structured filesystem allow this, the "head" is never over previous data in normal operation. you don't typically read the data back until the end of a cycle (whatever that cycle may be) or in a debugging condition. you simply append to the end. minimizing head movement, and thus increasing mtbf (replacing a disk in those things is costly)

this is also extremely useful for logging to WORM media (write once, read many), for security logs mostly. you don't want a hacker to be able to remove them, no matter what they do

Re:Shutdown versus power off

[morpheus800e]

Automatic head parking has been around for a LONG time - Here's [custhelp.com] the data sheet from the 120 MEGAbyte drive that I had years ago. It came in my 386. Note the following line, about half-way down:
"Turning the system power off causes the WD Caviar to perform an automatic head park operation."

It wasn't a high-end drive at the time, (just a consumer-level IDE drive), and was utterly obsolete years ago, yet it still had the technology to park the heads out of the way when power is disconnected. There's no way that turning off power to a new drive is going to physically damage it. You just might lose the data on it.

Re:Horrible headline

[TheRaven64]

I hope you deal with very large documents. If you are dealing with things under a couple of MBs then you will get better performance by overwriting the entire file than by writing small chunks (at least, on mechanical hard disks - it's different if you are using Flash). Hard disks are best at transferring large amounts of contiguous data - small reads and writes can cripple their performance.

Not really +1, Insightful

[hummassa]

Because old stuff can be overwritten when you fill the whole disk. As I mentioned in other posting, data writes are Real Fast in log filesystems, but data reads are Real Slow.

The biggest problem of this filesystem [nilfs.org] (link is missing from the original posting) is that it's Not Really Ready (among other important stuff, mmap() is not implemented yet).

Re:Shutdown versus power off

[heson]

You might want to read this http://linuxmafia.com/faq/Filesystems/reiserfs.htm l [linuxmafia.com]

Re:HDFS (home-dir FS)?

[Anonymous Coward]

http://www.kitenet.net/~joey/svnhome.html

Re:Shutdown versus power off

[0xABADC0DA]

Close, but no cigar:

1. It goes into the OS filesystem cache. After 5 seconds the modified data gets flushed to the disk (sometimes set to 30 sec).
2. It is written to the hard drive. Here, it sits in the hard drive controller's on-board cache until the head arrives at the write point, which is a fraction of a second.
3. It is written to disk.

So it *can* happen that data is not written properly, but unlike the scary picture you paint it is extremely unlikely. Even if you just saved your data, just do a sync and you'll be fine turning the power off.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:HDFS (home-dir FS)?

[RosenSama]

How about mounting a WebDAV. I read that subversion can work this way when I upgraded to 1.2. Quoting from http://subversion.tigris.org/svn_1.2_releasenotes. html [tigris.org]

Autoversioning is a feature whereby generic WebDAV clients can write to a DeltaV server (like mod_dav_svn), and the server performs commits silently in the background. This means that if you use Apache httpd as your Subversion server, then most modern operating systems can mount the repository as a network share, and non-technical users get "transparent" versioning for free. (Of course, technical users can still use Subversion clients to examine repository history.)

Re:Bloat?

[DrSkwid]

for some of us, our whole file system is append only :

http://cm.bell-labs.com/sys/doc/venti/venti.html [bell-labs.com]

http://cm.bell-labs.com/magic/man2html/8/venti [bell-labs.com]

Sean Quinlan [bell-labs.com] now works at Google, I'm not sure if Sean Dorward does, but it seems most of the other people who built plan9 at Bell Labs do.

Re:HDFS (home-dir FS)?

[Dr.Dubious DDQ]

You could possibly implement it with DavFS [sourceforge.net]...

Re:Linux files systems suck ass..

[csirac]

So what are the choices? ext2/ext3 which are slow, reiserfs which sucks ass when it breaks..

Apart from the big (production quality) alternatives like IBM's JFS (which I use myself) and SGI's XFS (and Reiser - "Reiser sucks when it breaks" is so 1999) Linux additionally supports the following filesystems (from http://www.xenotime.net/linux/linux-fs.html [xenotime.net], also try http://www.tldp.org/HOWTO/Filesystems-HOWTO.html [tldp.org]):


* accessfs: permission filesystem
* AFS FAQ
* AutoFS
* AVFS: A Virtual File System
* AVFS: A Virtual Filesystem
* BeFS for Linux2.4
* BeOS filesystem for Linux
* BFS UnixWare, Linux Implementation of
* CDfs
* CIFS
* Cluster File Systems Home
* Coda File System
* Crypto HOWTO
* convertfs: convert Linux filesystems
* DAFS: Direct Access File System
* Devfs (Device File System) FAQ
* efslook: read/debug EFS filesystems (ported to Linux & x86) {new}
* Enhanced Loopback (for XFS)
* E2fsprogs: Ext2 Filesystem Utilities
* E2fsprogs: Ext2 FS Utilities
* Ext2 Compression Extension
* FSDEXT2: ext2 filesystem for Win95
* ext2fsnt: Linux Ext2 filesystem for Windows NT driver
* ext2 fs resize utilities
* ext2 online growth patch (adilger)
* Explore2fs
* FHS: Filesystem Hierarchy Standard
* FHS Test Suite
* Filesystems HOWTO
* FiST: File System Translator
* FreeVXFS
* fsv: 3D File System Visualizer
* Global File System (Sistina)
* GNU ext2resize: ext2 filesystem resizer
* HFS+ filesystem
* HFS+ filesystem #2
* InterMezzo FS
* JFFS (axis.com)
* Journaling Flash File System, v2
* JFS for Linux (IBM)
* journal_fs report (OSDL)
* Kragen's Amazing List of Filesystems
* Large File Support in Linux
* Large File Summit (LFS) stuff
* Large File / File System Support
* Linux EXT2 salvage utility
* Linux Ext2fs Undeletion mini-HOWTO
* Linux FAT-32 support
* Linux filesystem redundancy
* Linux Links: File Systems
* Linux NFS FAQ
* Linux RAID Solutions
* LUFS: Linux Userland File System
* Lustre & Lustre Light filesystems
* NFS project
* NFSv4 for Linux 2.4
* Linux NTFS file system support
* loop-aes cryptoloop device