[ale] Ext4 adoption anyone?

[Jeff Hubbs]

These newer filesystems, including the ones used through FUSE - are any 
of them considered as reliable as ext3, jfs, xfs?

Pat Regan wrote:
> Michael B. Trausch wrote:
>   
>> Yes, but the disk format is unstable as of -rc2.  It's marked as highly
>> experimental.  I attempted (and failed) with -rc1 to use it on my extra
>> hard drive; it would not mount.  I'll be trying again with -rc2 or -rc3
>> here soon (-rc3 will be coming out soon).
>>     
>
> The goal was a stable disk format by the end of 2008, and they missed
> that.  Not by a whole lot so far, at least.
>
>   
>> The config option under filesystems currently reads:
>>
>> <*> Btrfs filesystem (EXPERIMENTAL) Unstable disk format
>>
>> I'd like to see them do with filesystems like they did with device
>> drivers, and add a "staging" option to the filesystem driver selection
>> menu, but I don't know if they're going to do that or not.
>>     
>
> I doubt we'll get a subheading like that for filesystems.  It sounds
> like they really don't want to have any experimental filesystems in the
> tree, if they can manage it.
>
>   
>> Yeah, ZFS is pretty memory-intensive all on its own.  I am pretty sure
>> that its target is dedicated file servers.  :)
>>     
>
> It is, but I'm pretty sure that with zfs-fuse it was even doubling up on
> disk cache.  The kernel cached everything, and then the zfs library did
> its own caching on top of that.
>
>   
>> Indeed.  I am starting to see Torvalds' backup method as becoming
>> practical---keep everything important on the Internet so that you can
>> easily restore what you're doing.  This doesn't work for the file
>> server that I have since it has music and photos, but it works pretty
>> well for everything else that I do.
>>     
>
> My files aren't popular enough for the Torvalds method.  I have only 3
> directories that I backup very regularly.  My repositories, my working
> directory, and my documents directory.  Oh, and a handful of dot-files
> (even though the important dirs, like .emacs.d and .sawfish, are in
> repositories).
>
> I just rsync these to a host on the internet, but I manually dump them
> to a flash drive just in case.  I love flash.  It is terribly durable.
>
> I have WAY too many DVDs, even very good media, that I just can't read
> anymore.
>
>   
>> I know that bzr---at least when it started out---was pretty slow.
>> These days it's great with speed, at least in all the cases that I use
>> it for.  I don't pull the MySQL tree with it, but then again I don't
>> use the MySQL database server.  :-P
>>     
>
> I have an SVN tree that I keep synced up with the tree of a Quake 3
> based game.  Most of my usual commands are pretty much instantaneous.
> Some take a few seconds.
>
>   
>> bzr will look at trees and merge them based on their common ancestor.
>> There are constant improvements being made to bzr all the time; when I
>> started using it, it was a 0.1x release, and today they're at 1.11,
>> with active development still continuing.  The only thing I wish they
>> would have done is used a compiled language, but I think that once
>> development tapers off a bit, it will probably be independently ported
>> to C.  That said, though, for a Python program, it's ridiculously fast,
>> at least IMHO.  I've pretty well always been unhappy with software
>> written in Python, in terms of its speed and memory usage; bzr has
>> begun to change my perceptions of what a Python program can be and
>> shown that Python can be used for "serious" software, as opposed to the
>> simple one-off scripts that I tend to use it for.
>>     
>
> I have no fear of interpreted languages.  Perl and Python are both good
> at text processing, which is what version control is all about.
>
>   
>> I still wouldn't consider using it for a major software project, but
>> that's just me.  bzr is probably the only piece of complete software
>> that I use which relies upon Python, that isn't some form of "glue".
>> Also, its integration with Launchpad is wonderful, and the abillity to
>> push to private locations that I hold on the Internet is priceless.  I
>> imagine that Darcs probably has some way to do the same thing, pushing
>> to a machine over SSH that doesn't already have a Darcs installation,
>> because most DVCS tools seem to have that ability.  It's very nice, and
>> a wonderfully welcome "wishlist item" from the days of Subversion.
>>     
>
> At the time I started using it, Darcs required a Darcs install on the
> remove machine to push.  That has never been an issue for me.  I
> wouldn't be surprised if that isn't a requirement now.  Pulling
> definitely works over http, but I've never set up a public repository
> like that.
>
> The only bad thing I ever hear anyone say about Darcs is that it is
> "slow" for some definition of slow.  The biggest repository I work with
> is about 500 files in 16 meg.  I imagine it might very well be slow if
> you shoot way, way past that point.  I'm also pretty sure that most of
> the people complaining about the speed will never have a repository big
> enough to be slow.
>
> Pat
>