Milyen szempontból?
FreeBSD alatt legalábbis "nagy" fájlokkal már a kezdetektől nincs probléma, azaz a legszutyibb 386-osodon a legrégebbi FreeBSD-vel is tudsz GB-os fájlokkal dolgozni.
Logikailag a fájlrendszer (UFS1) mérete is elég nagy volt emlékeim szerint, az UFS2-nél ha minden igaz teljesen 64 bites, azelőtt gondot okozhatott 1-2 TB-nál nagyobb fájlrendszer kezelése (de fájlokat használhattál ennél nagyobbat is).
Vannak ACL-ek, van az EA-knak is helyük (UFS1-ben utóbbi kevésbé jó, UFS2-vel jobb).
Tud fájlrendszer szintű, de csak RO snapshotokat, lehet rajta kvótát használni (csak mint linuxosnak mondom, ott nem mindig triviális ;).
A 6-os, ill. 7-es verzióban már teljesen SMP biztos, bár bizonyos részek (pld. kvótakezelés) még magukkal húzhatják a giant lockot.
Specialitás a soft updates, amely a journalinghoz képest egy más megközelítést ad a fájlrendszer konzisztenciájának megtartására. Elméletben akár gyorsabb is lehet, mint a naplózás.
Hátránya, hogy azért ha jót akarsz, érdemes fsck-znod nem tiszta leállásnál, ilyenkor viszont használhatsz background fsck-t, amely miatt lényegében a snapshotot megcsinálták. Ez egy snapshotot készít a fájlrendszerről, azt ellenőrzi, majd az árva dolgokat (feltéve, hogy az SU konzisztens maradt) visszaírja az éles fájlrendszerre. Nagyobb fájlrendszernél (pár TB) géptől és a fájlrendszer paramétereitől függően egy fsck több tíz perc, vagy akár óra is lehet.
Nem tud online átméretezhetőséget, offline-ban viszont a growfs utillal növelhető (csak, csökkenteni nem lehet).
Nem tud osztott médiát kezelni, még úgy sem, hogy egy RW, a többi felhasználó RO. Természetesen ha mindenki RO, az működik, mint máshol is.
Nem "byte order neutral", azaz egy Sparc-on formázott fájlrendszert nem tudsz a csilivili PC-dben használni.
Nem tud storage tieringet, azaz bizonyos könyvtárakat, vagy fájltípusokat nem tudsz eltérő storage-okra tenni (pld. a .mp3-at SATA-ra, a .db-t pedig FC-re).
Van benne némi autotuning. Ha a fájlrendszer kevésbé telített, megpróbálja elkerülni a fragmentációt, ha már nagyon telített (8%), inkább az allokáció idejét próbálja csökkenteni.
Egy alap ext2 formázáshoz képest UFS2-vel formázni egy 128TB-os kötetet annyit tesz, mint teleporttal, vagy gyalog lemenni Szegedre, persze ez mindkét helyen tuningolható az mkfs/newfs oldalon. Mivel kevesebbet ír alapból, a formázott diszken is kevesebb metaadat lesz->több hely marad neked (konkrét méréseim nincsenek.
Lehet a fájlrendszerre címkéket akasztani, ezeket a rendszer képes okos GEOM classok révén felismerni és így a /dev-ben a címke alapján hivatkozhatsz a fájlrendszerre. Előnye, hogy akárhová kerül a diszk, akármilyen vezérlőre, az fstab-od mindig jó lesz.
Tuningolható a blokkméret és sok egyéb más is, ehhez mondjuk nem árt érteni is hozzá.
A különböző OS-ekben lévő UFS-ek az idők során elágaztak, a Solarisban az UFS például képes journalingra is és van benne pár extra okosság, illetve eltérés, amit máshogy oldottak meg. Pld. a FreeBSD-ben a nagy fájlrendszerek és a többi sallang miatt az UFS1 nem kompatibilis az UFS2-vel.
Nincs fájlrendszerrel egybegyógyított volume menedzsment, RAID és hibatűrést növelő checksumok (lásd ZFS).
Nincs verziózás sem.
Nagyjából ennyi jutott eszembe. Persze ezek nagy részét a linuxodon sem találod meg, legfeljebb több fájlrendszerben, vagy pénzbe kerülő termékben.