History log of /drivers/staging/lustre/lustre/include/lustre_mdc.h
Revision Date Author Comments
00d65ec8e158121638ad8fa049b5f58960ad560c 29-Aug-2014 John L. Hammond <john.hammond@intel.com> staging/lustre: move lustre_intent.h to ..

Move lustre/include/linux/lustre_intent.h to lustre/include.

Signed-off-by: John L. Hammond <john.hammond@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1accaadf2af8b871601d8b1cc8a06dce87b6a435 12-Jul-2014 Greg Kroah-Hartman <gregkh@linuxfoundation.org> staging: lustre: fix include relative paths

In drivers/staging/lustre/lustre/include there was a bunch of .h files
relying on ccflags to be set up right. Make all of them proper relative
paths so that ccflags for different subdirs can be now removed.

Cc: Andreas Dilger <andreas.dilger@intel.com>
Cc: Oleg Drokin <oleg.drokin@intel.com>
Cc: hpdd-discuss <hpdd-discuss@lists.01.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9fdaf8c0b92ab374f8501eb47855776afc928e45 12-Jul-2014 Greg Kroah-Hartman <gregkh@linuxfoundation.org> staging: lustre: remove top level ccflags variable

We need to remove the ccflags from the Lustre code as it prevents
individual object files from building properly in the kernel build
system. It also hids the horrid mess that the Lustre include files are
made up of.

Start out by removing the toplevel ccflags variable pointing to
drivers/staging/lustre/include/ as a valid include path. This requires
the absolute include markings of a bunch of .h and .c files, which is
also done here.

Cc: Andreas Dilger <andreas.dilger@intel.com>
Cc: Oleg Drokin <oleg.drokin@intel.com>
Cc: hpdd-discuss <hpdd-discuss@lists.01.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
44779340c6dcb8c858955c02b3aeef7d6b28a684 27-Apr-2014 Brian Behlendorf <behlendorf1@llnl.gov> staging/lustre: Limit reply buffer size

When allocating a reply buffer for the striping information don't
assume the unlikely worst case. Instead, assume the common case
and size the buffer based on the observed default ea/cookie size.

The default size is initialized to a single stripe and allowed to
grow up to an entire page if needed. This means that for smallish
filesystems (less than ~21 OSTs) where the worst case striping
information can fit in a single page there is effectively no
change. Only for larger filesystem will the default be less than
the maximum. This has a number of advantages.

* By limiting the default reply buffer size we avoid always
vmalloc()'ing the buffer because it exceeds four pages in size
and instead kmalloc() it. This prevents the client from
thrashing on the global vmalloc() spin lock.

* A reply buffer of exactly the right size (no larger) is allocated
in the overflow case. These larger reply buffers are still
unlikely to exceed the 16k limit where a vmalloc() will occur.

* Saves memory in the common case. Wide striped files exceeded
the default are expected to be the exception.

The reason this patch works is because the ptlrpc layer is smart
enough to reallocate the reply buffer when an overflow occurs.
Therefore the client doesn't have to drop the incoming reply and
send a new request with a larger reply buffer.

It's also worth mentioning that the reply buffer always contains
a significant amount of extra padding because they are rounded up
to the nearest power of two. This means that even files striped
wider than the default have a good chance of fitting in the
allocated reply buffer.

Also remove client eadatasize check in mdt xattr packing because
as said above client can handle -EOVERFLOW.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-on: http://review.whamcloud.com/6339
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3338
Reviewed-by: James Simmons <uja.ornl@gmail.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Bob Glossman <bob.glossman@intel.com>
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
38585ccc4627a9da381af9e912b756cfceb615a5 11-Feb-2014 Andreas Dilger <andreas.dilger@intel.com> staging/lustre/llite: fix O_TMPFILE/O_LOV_DELAY_CREATE conflict

In kernel 3.11 O_TMPFILE was introduced, but the open flag value
conflicts with the O_LOV_DELAY_CREATE flag 020000000 previously used
by Lustre-aware applications. O_LOV_DELAY_CREATE allows applications
to defer file layout and object creation from open time (the default)
until it can instead be specified by the application using an ioctl.

Instead of trying to find a non-conflicting O_LOV_DELAY_CREATE flag
or define a Lustre-specific flag that isn't of use to most/any other
filesystems, use (O_NOCTTY|FASYNC) as the new value. These flags
are not meaningful for newly-created regular files and should be
OK since O_LOV_DELAY_CREATE is only meaningful for new files.

I looked into using O_ACCMODE/FMODE_WRITE_IOCTL, which allows calling
ioctl() on the minimally-opened fd and is close to what is needed,
but that doesn't allow specifying the actual read or write mode for
the file, and fcntl(F_SETFL) doesn't allow O_RDONLY/O_WRONLY/O_RDWR
to be set after the file is opened.

Lustre-change: http://review.whamcloud.com/8312
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4209
Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Peng Tao <bergwolf@gmail.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
04eb2b7f3ff19685531945a484e78ab7b9376ccc 03-Dec-2013 Peng Tao <bergwolf@gmail.com> staging/lustre: fix build error when CONFIG_FS_POSIX_ACL is off

We need to include <linux/posix_acl_xattr.h> regardless of
CONFIG_FS_POSIX_ACL is set or not. Otherwise build fails as
reported by kbuild robot:

>> drivers/staging/lustre/lustre/llite/file.c:2965:2: error: implicit declaration of function 'posix_acl_dup' [-Werror=implicit-function-declaration]
acl = posix_acl_dup(lli->lli_posix_acl);
<many similar errors omitted>

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Cc: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Peng Tao <bergwolf@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
23f14e79ace301c1e46b52344ce02e72254c57b6 03-Aug-2013 Greg Kroah-Hartman <gregkh@linuxfoundation.org> staging: lustre: remove EXIT macro

We have a kernel-wide function tracing system, so use that instead of
rolling a custom one just for one filesystem.

Cc: Peng Tao <tao.peng@emc.com>
Cc: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
29aaf4962a3bce337d37176858ef1025b9f29cc4 02-Aug-2013 Greg Kroah-Hartman <gregkh@linuxfoundation.org> staging: lustre: remove ENTRY macro

We have a kernel-wide function tracing system, so use that instead of
rolling a custom one just for one filesystem.

Cc: Peng Tao <tao.peng@emc.com>
Cc: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
bdf43213f9e7faf980025f44ec82b80caf453e8d 22-Jul-2013 jcl <jacques-charles.lafoucriere@cea.fr> staging/lustre/mdc: layout lock rpc must not take rpc_lock

When a client issue an RPC to get a layout lock, it
must not hold rpc_lock because in case of a restore
the rpc can be blocking for a long time

Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3200
Lustre-change: http://review.whamcloud.com/6115
Signed-off-by: JC Lafoucriere <jacques-charles.lafoucriere@cea.fr>
Reviewed-by: Jinshan Xiong <jinshan.xiong@intel.com>
Reviewed-by: Johann Lombardi <johann.lombardi@intel.com>
Signed-off-by: Peng Tao <tao.peng@emc.com>
Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
d7e09d0397e84eefbabfd9cb353221f3c6448d83 02-May-2013 Peng Tao <bergwolf@gmail.com> staging: add Lustre file system client support

Lustre is the most deployed distributed file system
in the HPC (High Performance Computing) world. The patch
adds its client side support.

The code is not very clean and needs to live in drivers/staging
for some time for continuing cleanup work. See
drivers/staging/lustre/TODO for details.

The code is based on Lustre master commit faefbfc04

commit faefbfc0460bc00f2ee4c1c1c86aa1e39b9eea49
Author: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Date: Tue Apr 30 23:05:21 2013 +0400

LU-3244 utils: tunefs.lustre should preserve virgin label

Plus a few under-review patches on Whamcloud gerrit:
3.8 kernel support:
http://review.whamcloud.com/#change,5973
http://review.whamcloud.com/#change,5974
http://review.whamcloud.com/#change,5768
http://review.whamcloud.com/#change,5781
http://review.whamcloud.com/#change,5763
http://review.whamcloud.com/#change,5613
http://review.whamcloud.com/#change,5655

3.9 kernel support:
http://review.whamcloud.com/#change,5898
http://review.whamcloud.com/#change,5899

Kconfig/Kbuild:
http://review.whamcloud.com/#change,4646
http://review.whamcloud.com/#change,4644

libcfs cleanup:
http://review.whamcloud.com/#change,2831
http://review.whamcloud.com/#change,4775
http://review.whamcloud.com/#change,4776
http://review.whamcloud.com/#change,4777
http://review.whamcloud.com/#change,4778
http://review.whamcloud.com/#change,4779
http://review.whamcloud.com/#change,4780

All starting/trailing whitespaces are removed, to match kernel
coding style. Also ran scripts/cleanfile on all lustre source files.

[maked the Kconfig depend on BROKEN as the recent procfs changes causes
this to fail - gregkh]

Signed-off-by: Peng Tao <tao.peng@emc.com>
Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>