Daniel Phillips noted that his new Tux3 versioning filesystem is now operating like a filesystem, "the last burst of checkins has brought Tux3 to the point where it undeniably acts like a filesystem: one can write files, go away, come back later and read those files by name. We can see some of the hoped for attractiveness starting to emerge: Tux3 clearly does scale from the very small to the very big at the same time. We have our Exabyte file with 4K blocksize and we can also create 64 Petabyte files using 256 byte blocks." He went on to discuss some of the remaining features yet to be implemented, including atomic commits, versioning, coalesce on delete, a version of the filesystem written in the kernel, extents, locking, and extended attributes.
Reviewing the above list, Daniel decided he would work next on the coalesce on delete functionality, noting, "without this we can still delete files but we cannot recover file index blocks, only empty them, not so good." He added that at this time he was only going to focus on file truncation, "as soon as file truncation is added to the test mix we will see much more interesting behavior from the bitmap allocator, and we will discover some great ways to generate horrible fragmentation issues. Yummy." Daniel continued to point out that Tux3 is an open source project, and as such is always looking for others to participate, "whoever wants to carve their initials on what is starting to look like a for-real Linux filesystem, now is a great time to take a flyer. The code base is still tiny, builds fast, has lots of interactive feedback and is easy to work on. And you get to put your email address near the beginning of the list, which will naturally write its way into the history of open source. Probably."
New Filesystem Operations?
Is anybody looking at new kinds of filesystem operations? For example, inserting new blocks in the middle of a file, or deleting blocks from the middle of a file. That kind of thing could be useful for editing in a video-recorder type of application.
That's just one example.
That'd have to be at the VFS level, wouldn't it?
Those sorts of splicing operations would have to exist at the VFS level, wouldn't they? And, I suppose there would need to be a new userspace API for it.
I forget, but is there a way in the existing APIs to zero out a portion of an existing file so as to make a non-sparse segment sparse? That could get you most of the way there, since you could at least "sparse-ify" deleted sections, reclaiming the disk space, and use other metadata in user-space to indicate the logical order of file fragments. Unfortunately, the only way I know of currently to make a sparse file is to use fseek() to seek beyond the end of the current file.
Actually splicing at the filesystem level by dropping or reordering blocks seems like it would be very sensitive to a specific filesystem's block size, and it would require either filesystem-specific APIs, or new VFS support and teaching existing filesystems new tricks.
--
Program Intellivision and play Space Patrol!
New Filesystem Operations?
I just added "support hole punch" to the Tux3 things to do list.
I just did it yesterday, it
I just did it yesterday, it worked like a charm
What about...
Why don't they just merge the benefits of all this shiny-new file systems into a unique, super fast, distributed and versioned filesystem? Like could be ext4_new = ext4_old + btrfs + tux3 + etc?
Otherwise more overhead in testing our apps on different filesystem :P
better yet
why dont they just give up and use OS X. they will never match ZFS, and it is sad (but amusing at the same time) to see them try.
Uhhh...
Because OS X is slow as molasses?
OS X
OS X is proprietary.
I rather run OpenSolaris then.
OS X
Hmm..can't say I see any OS X *OR* OpenSolaris embedded devices around, which would seem to indicate *NEITHER* are as insanely customizable as linux.
Extra filesystems mean extra choices and in turn extra roles linux can potentially fill.
Is the iPhone not OSX on ARM
Is the iPhone not OSX on ARM ?
Ooooh, they compiled BSD on
Ooooh, they compiled BSD on ARM, oohhh...
Shoo, Apple fanbois. Begone pest!
FreeBSD supports ZFS
FreeBSD supports ZFS
But does it already do SMP?
But does it already do SMP?
Yup, with fine grained
Yup, with fine grained locking
Linux has fuse-zfs.
Linux has fuse-zfs.
..which is absolutely
..which is absolutely useless.
OK I take that back. Tested
OK I take that back. Tested newer version 0.5.0, and it works superb!
I wonder if the FUSE implementation also features atomic writes and always-valid-on-disk state of files.
Anyways, really looking forward to see Tux3 running, but given that Sun needed 5 years for ZFS, it might take a while.
FreeBSD doesn't support ZFS
"FreeBSD supports ZFS" is great for gratuitous trolling, but the reality differs.
The ZFS code in FreeBSD is still marked experimental for a reason. It's definitely too unstable for production use.
I keep trying it, on 7-STABLE and on very recent -current, and I'm often experiencing odd behaviors (the system either locks up or becomes so slow that it is unuseable). I also had a corrupted filesystem, that was just unfixable. As soon as I entered a directory, the system rebooted.
Having some ZFS code doesn't mean that FreeBSD supports ZFS. Please advocate things you actually used in the real life.
By suggesting so I'm
By suggesting so I'm assuming that you have given up and are, in fact, using OS X. So that begs my question. Why in the hell are you posting on this forum then? Go off into the distance and enjoy your OS X love.....
The trolling is much better
The trolling is much better here ;)
Ah, but OS X does have UNIX
There *is* a UNIX- derived kernel under OS X, (specifically BSD UNIX-derived). This site isn't specific to Linux.
--
Program Intellivision and play Space Patrol!