LU-12561 ldiskfs: Remove unused 2.6.x patches Lustre no longer supports 2.6.x kernels, so remove the ldiskfs patches which are no longer used after removing RHEL6 and non-3.x SLES11 support. Test-Parameters: trivial Signed-off-by: Patrick Farrell <pfarrell@whamcloud.com> Change-Id: Icc31c9704669367ece16ec0c09746611cad32ee8 Reviewed-on: https://review.whamcloud.com/35550 Tested-by: jenkins <devops@whamcloud.com> Tested-by: Maloo <maloo@whamcloud.com> Reviewed-by: James Simmons <jsimmons@infradead.org> Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
LU-12151 osd-ldiskfs: pass owner down rather than transfer it Currently, for object creation, initially uid/gid set as 0, and then osd_quota_trasfer() is called to correct space accounting for non-root users, function call is like: |->osd_create |->osd_create_type_f |->osd_mkreg |->ldiskfs_create_inode |->ext4_new_inode() ->owner as NULL, create 0 as uid/gid |->osd_attr_init |->osd_quota_transfer ->which will change uid/gid again for above. This is inefficient since osd_quota_transfer() is a more heavy operations, we could just pass downer owner(uid,gid), project quota will inherit from its' parents automatically when creating inode. Some distros ext4 still did not support passing @owner down, that is (rhel6,sles11) we just added extra @owner arg in ldiskfs_create_inode() to make build system happy, and we could add similar support to older kernel if that is really needed. Command: $ salloc -N 32 --ntasks-per-node=24 mpirun -np 768 mdtest -n 2000 -F -u -d <mnt> Without Patch: Users Speed root 175741.938 ops/sec non-root 108631.673 ops/sec Patched: Users Speed root 184775.286 ops/sec non-root 185218.466 ops/sec Patch improved ~80% for non-root users and we reached same speed for both root and non-root users. Change-Id: I57b0d2a6913268448c0ed90cfe76bd9f051b0b40 Signed-off-by: Wang Shilong <wshilong@ddn.com> Reviewed-on: https://review.whamcloud.com/34581 Tested-by: Jenkins Reviewed-by: Andreas Dilger <adilger@whamcloud.com> Tested-by: Maloo <maloo@whamcloud.com> Reviewed-by: Yang Sheng <ys@whamcloud.com> Reviewed-by: Oleg Drokin <green@whamcloud.com>
LU-6030 ldiskfs: split pdirop patch Split pdirop patch as two parts. One for Nlevel-htree and Largedir, other one for pdirop and htree-lock. Also doing some cleanup work to reduce the patch size. Signed-off-by: Yang Sheng <yang.sheng@intel.com> Change-Id: I08b65d9098be95994f44748dbf14afa9f6d5b372 Reviewed-on: http://review.whamcloud.com/14264 Tested-by: Jenkins Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Reviewed-by: Bob Glossman <bob.glossman@intel.com> Tested-by: Maloo <hpdd-maloo@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-6030 ldiskfs: Remove alloc-policy patch Remove alloc_policy & wantedi two patches since they are no longer used. Signed-off-by: Yang Sheng <yang.sheng@intel.com> Change-Id: Ia283e16afe9d35d667c48e38db83d2a9cacb152c Reviewed-on: http://review.whamcloud.com/14299 Tested-by: Jenkins Tested-by: Maloo <hpdd-maloo@intel.com> Reviewed-by: James Simmons <uja.ornl@yahoo.com> Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Reviewed-by: Bob Glossman <bob.glossman@intel.com>
LU-5510 scrub: ldiskfs_create_inode returns locked inode There was race condition between creating new inode and OI scrub: the OI scrub may find the new created inode just after the creator creating it but before setting the LMA EA. Originally, to resolve such trouble, the creator will set the new created inode's state as LDISKFS_STATE_LUSTRE_NOSCRUB. But such state is set after the new inode unlocked. So the OI scrub still has some chance to find the new created inode with neither LDISKFS_STATE_LUSTRE_NOSCRUB nor LMA EA. Be as improvement, this patch makes the ldiskfs_create_inode() to return the new created inode with lock. The caller can set more state (not only for LFSCK, but also for other purposes in future) on the new created inode before unlock it. Signed-off-by: Fan Yong <fan.yong@intel.com> Change-Id: Idc1a8fbd3701f7e431ef4b7858cfdf4674d74add Reviewed-on: http://review.whamcloud.com/13187 Tested-by: Jenkins Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com> Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Tested-by: Maloo <hpdd-maloo@intel.com>
LU-2760 ldiskfs: update rhel6.3 series to handle mkdir errors ext4_mkdir can fail in several paths to dirtying an inode but the errors aren't caught. This patch adds the upstream commit that handles the errors and adjusts the dependent patches accordingly. Signed-off-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: James Simmons <uja.ornl@gmail.com> Change-Id: If86538e88c7386a06016ffae6893bacc8ba131e4 Reviewed-on: http://review.whamcloud.com/5279 Tested-by: Hudson Tested-by: Maloo <whamcloud.maloo@gmail.com> Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
LU-2473 ldiskfs: Reorganize ldiskfs kernel patches This commit makes no changes to the patches, only moving their location. For some time we have supported only a single kernel per major OS release, e.g. RHEL 6.3, or RHEL 6.2, but not both. While it is understandable to only support a single kernel, it is quite another to intentionally destroy the patchset for the previous kernel every time we upgrade. This makes the logistics of upgrading an OS release (even a minor one like RHEL 6.2 to 6.3, or 6.3 to 6.4) quite complicated. We should really start a new patch series when we update support for a new kernel. That way we can leave the patch sets for previous kernels in place. We do not need to "support" them, but at least leaving them unmolested until the users of the previous patch set have time to upgrade would be greatly appreciated. This commit attempts to organize the patches into subdirectories according to the kernel/os in which they were first created. A later commit will then add support for RHEL6.4. Also, fix build/confirmpatches.sh to allow checking ldiskfs/kernel_patches (a bug prevent checking anything but the default). Extend both confirmpatches.sh and clearpatches.sh to work with series files that point to patches organized into subdirectories. Change-Id: I6552fc271fff1f00657ba1430c4a1215dea5b530 Signed-off-by: Christopher J. Morrone <morrone2@llnl.gov> Reviewed-on: http://review.whamcloud.com/4803 Reviewed-by: James Simmons <uja.ornl@gmail.com> Tested-by: Hudson Reviewed-by: Jeff Mahoney <jeffm@suse.com> Tested-by: Maloo <whamcloud.maloo@gmail.com> Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>