Heh, Brian Foster complained that he could create filesystems that do this on for-next during the first mount attempt: [62548.735187] XFS (dm-1): Log size 4497 blocks too small, minimum size is 4499 blocks [62548.742853] XFS (dm-1): AAIEEE! Log failed size checks. Abort! I started looking into why mkfs and mount have different ideas about the minimum log length, and discovered that the struct xfs_trans_res between kernel and userspace have vastly different ideas about how much space a transaction type requires. Most of the problems are easily fixed by constructing a more complete phony superblock in mkfs' max_trans_res() (patches soon), but I ran into a nasty one that I cannot resolve in tr_symlink. In fs/xfs/, MAXPATHLEN is defined as 1024, and returns -ENAMETOOLONG (set) or -EFSCORRUPTED (get) if it is fed a symlink with a target longer than 1024 bytes. However, xfsprogs picks up the definition offered by libc, which is PATH_MAX (4096). Unfortunately, this also means that xfs_repair only complains if the target is longer than 4096 bytes. AFAICT the other filesystems allow 4k symlink targets, but XFS' special definition has been there at least since git-prehistory. Soooo... which is the correct value? We could raise the kernel limit to 4k with at least the obvious problem that old kernels can't read such symlinks, or lower the xfsprogs limit to 1k, with the problem that at least in theory this would result in xfs_repair flagging things it wouldn't have before. My cautious side says lower xfsprogs, but I'll ask the list anyway. :) --D -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
