[LU-1382] Quota are broken by filesystem extension

Mon, 9 Jul 2012 16:14:03 +0000

After a filesystem extension (ie add of new OSTs), quota are not propagated on newer OSTs.
Running quotacheck, quotaoff or quotaon doesn't change anything to the picture.

Here is the output of lfs quota on a fs where OST 0x64..0x80 have been freshly added :

# lfs quota -v -u foo /scratch/
Disk quotas for user foo (uid 1000):
    Filesystem kbytes quota limit grace files quota limit grace
 /scratch/ 6985760 21474836480 22548578304 - 8 2000000 2100000 -
scratch-MDT0000_UUID
                    12 - 131072 - 8 - 5120 -
scratch-OST0000_UUID
                     0 - 131072 - - - - -

[...]

scratch-OST0062_UUID
                     0 - 131072 - - - - -
scratch-OST0063_UUID
               1425412 - 1572864 - - - - -
scratch-OST0064_UUID
                     0 - 131072 - - - - -
scratch-OST0065_UUID
                     0 - 131072 - - - - -

[...]

scratch-OST0076_UUID
                     0 - 131072 - - - - -
scratch-OST0077_UUID
                     0 - 131072 - - - - -
scratch-OST0078_UUID
                     0 - 0 - - - - -
scratch-OST0079_UUID
                     0 - 0 - - - - -
scratch-OST007d_UUID
                     0 - 0 - - - - -
scratch-OST007e_UUID
                     0 - 0 - - - - -
scratch-OST007f_UUID
                677892 - 0 - - - - -
scratch-OST0080_UUID
                     0 - 0 - - - - -

The side effect is that (most of the) newly created files are not enforced as fas as they are (mostly) created on the new OSTs (the accounting looks good so far).
The workaround we have consist of removing quota (-b 0 -B 0 -i 0 -I 0) then re-applying them, user by user, but it would be better if quota were automatically propagated during add of new OSTs or, at least, handled by a quotacheck.

Thanks,

Whamcloud Community JIRA

[LU-1382] Quota are broken by filesystem extension