[ale] Ext4 adoption anyone?

[Michael B. Trausch]

On Thu, 22 Jan 2009 05:03:37 -0500
Pat Regan <thehead at patshead.com> wrote:

> Zfs, tux3, and btrfs all seem to use copy-on-write.  The act of
> automatic versioning would be trivial to implement with any of them.
> The trouble would be deciding what to keep and what to throw away.  Do
> you want to keep every revision of a log file every time a line is
> flushed?  I imagine not, but which revisions do you keep?
> 
> I'd be pretty happy if the filesystem kept at least one copy around
> after delete, at least for a little while.
> 
> I also noticed that btrfs has been merged into one of the 2.6.29
> release candidates.  It sounds like the on disk format has been
> stabilized.  I might get to test this guy out on my home directory
> sooner than I thought.

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

> > That said, I am actually kind of surprised that more filesystem 
> > development isn't happening that way.  I think it'd be interesting
> > to actually move to a model where most filesystem code resides
> > outside of the kernel, but only because I think that is probably
> > better since FUSE plugins can run on any platform that supports
> > FUSE.  I like the idea of being able to use a single filesystem
> > "driver" on multiple UNIX-like systems, ensuring compatibility
> > between them.  Today, it's still a pain to read media from FreeBSD
> > on Linux, and vice versa---FreeBSD supports ext2 only, last I
> > checked, and Linux still makes you do some manual tweaking to mount
> > UFS media from any system that uses a variant of that filesystem
> > format.  *shrugs*
> 
> I rarely share a disk between machines, unless it is fat32.
> 
> My fear of fuse for my home directory, at least with zfs, is speed and
> memory consumption.  zfs-fuse did a pretty good job of pushing me into
> swap when I 'only' had 2 gig of ram in my laptop :).

Yeah, ZFS is pretty memory-intensive all on its own.  I am pretty sure
that its target is dedicated file servers.  :)

I will use FATxx filesystems for interchange for the moment, but I
don't like doing that.  I don't trust such filesystems to last a very
long time, since they typically tend to bork themselves when multiple
operating systems get at them.  fsck.vfat is my friend there, but I
don't put anything on an FATxx filesystem that I don't have on at least
one "real" filesystem.


> > Ahh.  I thought you meant RCS, the classic version control system.
> > I use Bazaar (bzr) myself; I used Subversion for a long time before
> > that, but I don't think I could look back even for a very large
> > purse of money.  I can't imagine _not_ using bzr for VCS tasks any
> > more.
> 
> I can't even imagine using RCS.  I try to forget that it ever even
> existed :).  I won't give up my distributed vcs, ever.  I don't think
> I could manage.

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.

> > I use git, but only for pulling things which already use it.  I like
> > it as well, though I like some of the ways that bzr does things
> > better since the branch model is much more distributed, and you
> > don't *have* to work with all of the branches in a given tree when
> > pulling it.  My understanding of git and other DVCS tools is that
> > they are repositories housing a collection of branches, whereas
> > with bzr you just get the branch.  You can have multiple branches
> > in the same directory and pool storage between them if you'd like,
> > but it's not required.  Not sure how Darcs works at its lower
> > levels, but reading on WP leads me to think it is probably closer
> > to git's model than it is bzr's.
> 
> As far as I can tell, Darcs is pretty unique.  I'm a little bit behind
> on the state of the competition, though.  A quick look at my directory
> of repositories says I've been using it since at least April 2004.  I
> probably stopped caring about other systems a few years later :).
> 
> What I do know is that sometimes I talk to friends about how they use
> their revision control systems.  From what I can gather, Darcs does a
> better job of conflict resolution on merging.  Darcs will make an
> attempt to apply patches in different orders and it does a very good
> job of tracking patch dependencies.
> 
> Darcs is likely the slowest, but it seems that it does more work for
> me.

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

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

	--- Mike

-- 
My sigfile ran away and is on hiatus.
http://www.trausch.us/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://mail.ale.org/pipermail/ale/attachments/20090122/b0fe478d/attachment.bin