On Sun, Jun 04, 2017 at 10:37:36PM +0100, Al Viro wrote: > On Sun, Jun 04, 2017 at 12:31:34PM -0700, Linus Torvalds wrote: > > > and in particular the patch in there that just makes UFS use MAX_LFS_FILESIZE: > > > > https://bugzilla.kernel.org/attachment.cgi?id=256853&action=diff > > > I'm inclined to just apply it, since clearly the default 2G limit > > isn't appropriate for UFS, although it would perhaps be a good idea to > > figure out just what the true UFS maximum file size can be.. The > > on-disk "ui_size" field seems to be a 64-bit entity, so > > MAX_LFS_FILESIZE is certainly better, but there's probably some index > > tree limit that depends on the block size or whatever. > > Depends. There had been a lot of UFS variants (hell, ext2 is one), so > limits differ. They are also kernel-dependent. > > One hard limit is the same as in ext2 - indirect blocks contain pointers > to blocks, so you get (10 + n + n^2 + n^3)*block_size, where n is <grabs some coffee> 12 + n + n^2 + n^3, sorry. 12 direct blocks, plus usual indirects. Something like (completely untested) u64 ufs_max_bytes(struct super_block *sb) { struct ufs_sb_private_info *uspi = UFS_SB(sb)->s_uspi; int bits = uspi->s_apbshift; u64 res; if (bits > 21) return MAX_LFS_FILESIZE; res = UFS_NDADDR + (1LL << bits) + (1LL << (2*bits)) + (1LL << (3*bits)); if (res >= (MAX_LFS_FILESIZE >> uspi->s_bshift)) return MAX_LFS_FILESIZE; return res << uspi->s_bshift; } ought to calculate the right thing for modern UFS variants; I would leave the anything other than UFS_MOUNT_UFSTYPE_44BSD and UFS_MOUNT_UFSTYPE_UFS2 alone.
