Some people seem to think FreeBSD and Linux are on equal grounds. They’re not. FreeBSD is literally a platform derived from highly skilled researchers.
That's 30+ years ago. it doesn't count anymore. That's about the same amount of time that GNU/Linux has been around. Resting on the laurels of the BSD's birthright is akin to a hypothetical son of Einstein saying "I'm the son of Einstein, I don't need to prove I'm smart."
Making bold claims like that without any objective discourse is disrespectful IMO. Not one reasonable deficiency was mention in comparison to XFS. Seriously, atleast give us something to look at.
Read my sig.
I've given metrics indicating that UFS has worse performance, and others dismissed it. I have no sources that will fit someone's criteria, because they have a preconceived notion of what's acceptable. Nothing less than confirmation bias that UFS2 is on equal/superior ground to Linux-based filesystems will work. It's the same as a bad defense attorney trying to dismiss evidence on the basis of bias, but presenting nothing here.
I've mentioned the UFS2 codebase is archaic and difficult to understand. You want support?
Kernel source for UFS2:
Code:
~/devel/freebsd-src/sys/ufs % cloc .
36 text files.
36 unique files.
2 files ignored.
github.com/AlDanial/cloc v 1.90 T=0.17 s (195.8 files/s, 257508.4 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
C 21 2645 9399 28793
C/C++ Header 13 273 1646 1965
-------------------------------------------------------------------------------
SUM: 34 2918 11045 30758
-------------------------------------------------------------------------------
Code:
~/devel/linux-4.4.293/fs/xfs % cloc --exclude_dir libxfs .
103 text files.
103 unique files.
2 files ignored.
github.com/AlDanial/cloc v 1.90 T=0.18 s (565.5 files/s, 331021.6 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
C 55 5774 12736 32808
C/C++ Header 46 796 1714 5760
make 1 9 24 91
-------------------------------------------------------------------------------
SUM: 102 6579 14474 38659
-------------------------------------------------------------------------------
Exclusion of libxfs is for direct comparison sake. They're on the surface about the same size, but there's some glaring differences.
1. UFS is organized into much larger files, which can make for difficult reading. This is purely a stylistic choice, but coming from a System V background I prefer this for kernel code.
2. Comments are 36% of the size of the UFS codebase, 38% for XFS.
3. I won't share GPL code, but if you aren't under a prohibition to look at V2 from your employer (I'm not, but I try to avoid v3) look through a few files, read the difference in the quality of comments. Actual comments from each:
UFS:
Code:
/*
* Restore user's disk quota because allocation failed.
*/
Code:
/*
* A virgin directory (no blushing please).
*/
XFS:
Code:
/*
* Invalidate any cached ACLs if the user has bypassed the ACL
* interface. We don't validate the content whatsoever so it is caller
* responsibility to provide data in valid format and ensure i_mode is
* consistent.
*/
Code:
/*
* xfs_find_handle maps from userspace xfs_fsop_handlereq structure to
* a file or fs handle.
*
* XFS_IOC_PATH_TO_FSHANDLE
* returns fs handle for a mount point or path within that mount point
* XFS_IOC_FD_TO_HANDLE
* returns full handle for a FD opened in user space
* XFS_IOC_PATH_TO_HANDLE
* returns full handle for a path
*/
There's a much higher verbosity in the XFS comments. Much of the files in the ufs code are also directly recycled from the mid-90s UCB code -- the codebase has certainly changed in nearly 30 years but this is not a good sign.
The original XFS implementation in IRIX was much, much bigger (80k+ lines in the kernel) and has been touched and tuned extensively. It's certainly possible for someone to make it even smaller than Linux has it.
As for mark's comments:
I wasn't saying you were, just that this is the same type of issue that infests linux. NIH==must write our own and stable==must replace ASAP.
That's all fine and good when you drag in 10s of millions of dollars PA.
Not that I don't agree, but outright aversion to replacement of a codebase that may take as much money to refurbish is something to consider. By the time someone rewrite UFS to be more acceptable to modern tastes (which necessitates removal of soft updates, as NetBSD did, among a lot more) you will be left with a case of theseus' ship.
What do you want? A file system or an academic research topic?
Nothing I posted was academic in nature. It was papers and docs published by the men who wrote it.
The so-called dual layer approach was for pragmatic reasons because it re-used a large swathe of code. There's nothing inherently bad about this approach. If I recall correctly, I read McKusick originally looked at XFS but realised it would take too long to get it working under FreeBSD. So, they took UFS1 and made it UFS2. Stable and quick to be developed.
Design decisions made 30 years ago need to be questioned man. Why has nobody else other than the BSDs done this? Why did all the System V UNIXes go on to develop their own proprietary filesystems and discard UFS (Hint hint, it's not licensing!). This design has obfuscated code that desperately needs to be understandable.
As for your comments... here's my problem and a problem that in large part extends to other debates:
Someone sets an impossibly high burden of proof/quality of evidence. When the person struggles or fails to offer proper evidence, the original person declares "I WIN" by default. This is not a court case, you are not iudex, jury, bailiff and such. We are having a debate, and you have to actually go in and debunk what's said -- which by and large you didn't do, and netiher has anyone else. It's also worth noting that if you apply what I just said to non-technical topics, it immediately shows the weakness in not entertaining ideas brought forth. Frankly, I'm not here to convince you XFS is the way to go -- if you've made up your mind it isn't, then so damn be it. I want someone to see this who may have the skills to lead such an effort, and say "Hey he's got a good idea, and he's offered to help on some capacity. Let's talk and see what we come up with." Which would be swell. I'd gladly consider that, though I'd insist my work be done on the freebsd fork I am doing work for rather than the direct upstream. I won't ever deal with the FreeBSD upstream again after seeing the gross problems that are weighing down the project and causing boneheaded decisions to be made.
IN CONCLUSION
I've stated all on the topic I feel inclined to. You have the evidence. I'm not the jury, you're not the jury. Make your mind and grow up, if you got angry or emotional over me attacking or questioning code that's been taken for granted and is trash IMHO, then you should re-evaluate things
