Date: Mon, 17 Dec 2001 02:16:39 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Tony <tony@ubik.demon.co.uk> Cc: Greg Lehey <grog@FreeBSD.org>, freebsd-hackers@freebsd.org, Hiten Pandya <hitmaster2k@yahoo.com> Subject: Re: [SUGGESTION] - JFS for FreeBSD Message-ID: <3C1DC607.7A757837@mindspring.com> References: <20011210220153.50612.qmail@web21102.mail.yahoo.com> <3C15AB82.FDF598A8@mindspring.com> <20011211182856.A67986@monorchid.lemis.com> <JGny5rAjuUH8IwoW@ubik.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Tony wrote: > 1. "JFS only operates on meta-data ... It does not log file data or > recover this data to a consistent state." [JFS overview] Yes. > "The logging style introduces a synchronous write to the log disk > into each inode or vfs operation that modifies meta-data." [JFS > overview] This is actually only for small directories an immediate metadata; most operations are in facted journalled, instead. Realize also that, though it doesn't do it, the synchronicity is once again an issue of ordered writes... so Soft Updates could be applied here. > This doesn't sound any more robust than FreeBSD's current > Softupdates. JFS wins though as fsck is faster on a reboot ... They actually discuss the failure modes for JFS, which include most reasons you would need to run an fsck. For a relatively quiescent system, the consistancy will be restored via journal pass, but if the journal consistency is bad, then it will do a full fsck. So it is likely to be necessary on IDE disks, which can spam sectors when writing during a power loss (things would be better un SCSI). Note that one of the reasons for the DC holdup time on the InterJet was to ensure the drive write cache was flushed, so that the drive was quiescent -- not in the middle of a write operation -- when DC finally failed. > Does AIX JFS log any file data? Yes (or ratherm, it journals it). And the EXT3 FS and BSD LFS do the same, and so do XFS and VxFS, though the last two do lazy synchronization. > 2. "The minimum file system size supported by JFS is 16Mbytes." [JFS > overview] Yeah, annoying, that. > "JFS will not support diskettes as an underlying file system." [JFS > overview] Just a size thing. > I believe AIX JFS does support diskettes / removable media. Yes, it does. > 3. Linux JFS does not support AIX JFS volumes. [various places] > > I am not clear whether this is inherent in some data structures > being different, or just that Linux doesn't process LVM info. This is AIX JFS vs OS/2 JFS. There would also be byte order issues, since the PPX running AIX operates in Motorolla byte order (network byte order), and not Intel byte order (wrong byte order 8^)). > JFS on AIX is "backward compatible" with Enhanced JFS (JFS2). JFS2 on AIX supports OS/2 JFS. > 4. The Linux JFS driver is noticeably incomplete [from JFS todo list]: > o SMP bugs. A given. They would need to introduce synchronization points in their SMP to address this. Linux SMP has similar problems in most code requiring ordered operations. > o Only 4096 byte block sizes currently supported. > (512, 1024 and 2048 should be available too.) It's a page granularity issue, due to explicit cache coherency requirements for an incompletely unified VM and buffer cache implementation. Going to the Intelk page size for the block size was an easy cop-out on the coherency update issues. > o No defrag tool. Actually, I saw one of these. You need to read the more detailed information, and not just the overview. > o FS resizing is not yet available. It can grow them, up to the size of the aggregate. The problem is that the LVM support for PP spanning (aggregating aggregates) is not there. Also, since they currently onbly permit a single aggregate set per partition, you tend to carve up your disks with no space to spare. In contrast, on OS/2 (or AIX, in the absence of LVM and/or disk spanning for lack of additional disks), you can have multiple aggregate sets per, so you usually end up with the whole disk being given over to a single monolithic block with multiple aggregate sets (one per FS). So I think this is just an artifact on the grow, and the lack of a defragmenter on a shrink (see above, about the defragger). > o Log file must be on the JFS partition. Not really a problem. > o Disk quotas are not currently supported. On FreeBSD, quotas should be implemented as a stacking layer with namespace folding anyway. I look at this one as "incentive". > o Extended Attributes and Access Control Lists are not functional. Actually file streams are not functional, which is not the same thing. > 5. "JFS is still guru-friendly (meaning that you need a Linux guru on > hand), but it will eventually grow into administrator-friendly." > [JFS FAQ] > > I'm not sure what this means, possibly just that the FS utilities > and man pages need some work. It means default installation using a RedHat or other Linux CDROM. > Undoubtedly JFS on FreeBSD would be expected to work with Linux JFS > volumes, but inter-operation with AIX JFS & JFS2 is also desirable. AIX JFS2 is achievable. AIX JFS is not, with that code, since it is a subset of the AIX JFS functionality, to begin with. > My questions at this point are: > * is there any IBM material, white papers or whatever, that I could > study to find out about JFS(2) on AIX? There are several "Redbooks", and a lot of white papers. > * where is a good place to start learning about FreeBSD file systems, > specifically UFS? Right now, the code. We need an FS writers guide, which is why I've made what offers I have with regards to other FS support, recently... to permit me to write one up, minimally, as a DDJ article on a porting project. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C1DC607.7A757837>