Since the introduction of the UFS2 filesystem (to the general public) in FreeBSD 5.0, there have been many questions from BSD users asking what does it actually mean for them. Recently when browsing the freebsd-current mailing list, I stumbled across a micro-FAQ about UFS2,
which might be of interest to OSNews readers.
> UFS2 is an extension to the well-known UFS. It adds 64 bit block
>pointers (breaking the 1T barrier), support for extended file storage,
> and a few other things.
It’s a pity that the changes are limited. I wish there was dynamic inode creation. It’s a pity that XFS is not ported to FreeBSD. I remember I read XFS team would have an easier job porting it to XFS (wasn’t it related to pagebuf?)…
It’s a pity that the changes are limited. I wish there was dynamic inode creation.
Static inodes do have some performance benefits (relating to the time required to seek from the inode to the beginning of the file)
However anyone who has ever run out of inodes certainly doesn’t appreciate them.
It’s a pity that XFS is not ported to FreeBSD.
Blame the GPL.
I remember I read XFS team would have an easier job porting it to XFS (wasn’t it related to pagebuf?)…
The page buffer extension is a big abstraction layer to circumvent the Linux VFS. XFS would have been easier to port to FreeBSD than Linux simply because the FreeBSD VFS greatly resembles the Irix one (because ultimately both projects came from the same codebase, even if they don’t share any code now)
So does this mean that I can attach any random name/value pair to a file, just like in BFS and XFS?
From http://acl.bestbits.at/about-ea.html
What are Extended Attributes?
Extended Attributes are arbitrary name/value pairs that are associated with files or directories. They can be used to store system objects (e.g., Capabilities of executables, Access Control Lists) and user objects (e.g., the character set or mime type of a file).
NetBSD has picked up a long abandoned logging file system from BSD4.4 called lfs and has it “mostly working” in 1.6 ( http://www.hhhh.org/perseant/lfs.html ). Looks like *BSD will finally have a native journaling filesystem option.
LFS is what it’s called, a log-structured (not “logging”) file system. It’s not a journaling file system.
This message has a short explanation of the differences, hope it helps.
http://mail-index.netbsd.org/current-users/1999/05/21/0027.html
Hmmm, so I was misled by http://www.netbsd.org/Misc/features.html ?
Yes. You must have misread it. It accomplishes many of the same things as journaling file systems, but works quite differently.
It’s a pity that XFS is not ported to FreeBSD.
Blame the GPL.
Errr… don’t blame the GPL, blame the BSD license. In order for XFS to find its way into *BSD, SGI would need to have BSD licensed it. It would be silly to expect them to give away their hard work with no expectation of return. The GPL insures that if anyone benefits from SGI’s code, SGI will benefit from their code.
Errr… don’t blame the GPL, blame the BSD license. In order for XFS to find its way into *BSD, SGI would need to have BSD licensed it. It would be silly to expect them to give away their hard work with no expectation of return. The GPL insures that if anyone benefits from SGI’s code, SGI will benefit from their code.
Yes, if those evil BSD programmers would just give up their overly restrictive license then corporations everywhere could protect their IP under the guise of making contributions to the public domain.
No, see, the problem here is releasing code under the GPL doesn’t really make it free.
…start blaming SGI. JFS is being ported to FreeBSD and is ALSO GPLed, see it on the JFS website at http://www-124.ibm.com/developerworks/oss/jfs/ .
So GPL is not the correct answer to the question “why XFS isn’t ported to FreeBSD”.
it’s not ported because there’s nobody capable that has cared enough to bother. end of story.
So GPL is not the correct answer to the question “why XFS isn’t ported to FreeBSD”.
Anyone can provide a patch. The problem is the resulting source code after applying the patch is no longer BSD licensed. No one with the technical prowess necessary to port XFS to FreeBSD is willing to put up with that sort of dual licensing issue. The resulting kernel tree could not be distributed, and it would most likely make precompiled kernels out of the question.
Besides, as has been mentioned earlier, SGI grafted their own abstraction layer (the page buffer) directly onto the VMM since they didn’t want to go to the work of converting XFS to support Linux’s largely discontiguous VFS. However, XFS would attach nicely to FreeBSD’s VFS, but this would involve removing the entire page buffer and trying to revert the codebase back to what it was like before the Linux port. This is an enormous amount of work, and no one is willing to go through with it.
cd /usr/ports/misc/xfs
make install
where’s the license issue here?
no matter how beautiful your port is it will *never* be part of the kernel, obviously. even if it were distributed under bsd i would guess that getting it into the GENERIC kernel would be next to impossible.
It’s good to see extended attributes come to FreeBSD, because, as Mac OS and BeOS have already shown, EA’s have the potential to make managing the OS even easier, once the programmers start taking advantage of them.
When will the journaling FS zealots learn that soft updates are just as nice a solution as journaling is?
And yes the BSD license is far “free-er” than the GPL, and yes GPL code will never make it directly into the BSD kernel for licensing issues, so even if XFS were ported FreeBSD it will never be a core feature of the kernel.
Honestly though, what realistically does XFS do that UFS2 can’t do? As far as filesystems go, it seems to be one of the better ones.
I care about XFS because it’s a pretty good filesystem. Check out the following link for a journaling filesystem comparison:
http://linuxgazette.com/issue55/florido.html
It’s not that I dislike UFS2, but if there’s a better solution why not have it? Otherwise you can as well ask what’s there Windows can’t do but BSD can… It’s not about getting the business done. It’s about efficiency, reliability, logic …
I can’t understand why GPL code cannot make into kernel, and kernel can’t contain code with different licensing schemes. All it matters is what part of the code is taken away/incorporated into other software. And if the part in question, XFS, is clearly commented (signed, etc.) to be GPL licensed I don’t think anyone would dare to use it. If they really want it that much they can rip it off from linux kernel too and conceal, it’s going to be same kind of infringement.