[LU-7890] EFBIG on 2TB singly stripped file with ZFS

• Type: Bug
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.9.0
• Affects Version/s: Lustre 2.5.0, Lustre 2.7.0, Lustre 2.8.0, Lustre 2.9.0
• Labels: zfs
• Severity: 3
• Assignee: Nathaniel Clark
• Reporter: Nathaniel Clark

Description

Commentary from Andreas:

It looks like cl_object_maxbytes() is returning a 2TB limit, even though the OSC has maxbytes=2^63.

debug.cli.txt-00000080:00000001:11.0:1458243131.430707:0:19947:0:(vvp_io.c:1060:vvp_io_write_start()) Process entered
debug.cli.txt:00000020:00000001:11.0:1458243131.430708:0:19947:0:(cl_object.c:440:cl_object_maxbytes()) Process entered
debug.cli.txt:00000020:00000001:11.0:1458243131.430709:0:19947:0:(cl_object.c:448:cl_object_maxbytes()) Process leaving (rc=2199023251456 : 2199023251456 : 1fffffff000)

cl_object_maxbytes() is getting this data from lov_object_maxbytes() lsm->lsm_maxbytes but I don't know why that is 2TB.

I see why this is. In lsm_unpackmd_common():

        if (stripe_maxbytes == LLONG_MAX)
                stripe_maxbytes = LUSTRE_EXT3_STRIPE_MAXBYTES;

        if (lsm->lsm_stripe_count == 0)
                lsm->lsm_maxbytes = stripe_maxbytes * lov->desc.ld_tgt_count;
        else
                lsm->lsm_maxbytes = stripe_maxbytes * lsm->lsm_stripe_count;

LLONG_MAX == MAX_LFS_FILESIZE == 2^63 so lsm_unpackmd_common() thinks that this is uninitialized. It also needs to avoid overflow here.

Issue Links

• is related to: LU-9862 The patch that landed for LU-7890 leads to static checker errors

Comments

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/19066/
Subject: LU-7890 lov: Ensure correct operation for large object sizes
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 3ddcf5b4a13851805f15b39aa1e95aee9b291132