Early Bird Discount Ending Friday
Register By March 20 and Save $50
Time is running out to save $50 on your registration for the
<http://opensfs.org/events/lug-2015/> 13th annual LustreR User Group (LUG)
conference. Register by Friday, March 20 to take advantage of the special
early bird registration discount. After March 20, the LUG registration rate
will be $575.
<http://opensfs.org/events/lustre-developer-day/> >> Register Now <<
This year, LUG 2015 will be held on April 13-15 at the
Denver Marriott City Center in Denver, CO, and will feature topics
* Lustre 2.8 and Beyond
Speaker: Andreas Dilger, Intel
* Lustre & Kerberos: In Theory and in Practice
Speaker: Sebastien Buisson, Bull
* Correlating Multiple TB of I/O Performance Data to User Jobs
Speaker: Michael Kluge, ZIH
* Lustre Network (LNET) Router Configuration and Tuning
Speaker: John Fragalla, Seagate Technology
New speakers and session highlights are being posted daily.
<http://opensfs.org/lug-2015-agenda/> View the full LUG 2015 agenda to see
Lustre Developer Day
OpenSFS is pleased to host the
<http://opensfs.org/events/lustre-developer-day/> LUG Developer Day on April
16. This is a new event to help provide Lustre developers and those
interested in doing Lustre development a chance to meet face to face. The
April Developer Day will include discussion on Kerberos, security, patchless
Idiskfs servers, lock ahead and strided locking, Lustre on ZFS, and more.
Registration is $125 and is limited to 50 attendees. Visit the
<http://opensfs.org/events/lustre-developer-day/> Lustre Developer Day
website to view the agenda and learn more.
OpenSFS Board Meeting and Community Discussion
All LUG 2015 attendees are invited to join the OpenSFS Board of Directors
for a discussion on Tuesday, April 14 from 5-6pm on OpenSFS community and
industry topics. This discussion will be held in the LUG general session
room but is not part of the official LUG agenda.
Work Group Meetings
All OpenSFS <http://opensfs.org/participants/> and EOFS
<http://www.eofs.org/> members are invited to participate in the OpenSFS
Work Group meetings being held in conjunction with LUG.
* <http://wiki.opensfs.org/Benchmarking_Working_Group> Benchmarking
o Tuesday, April 14: 6:00-7:00pm
* <http://wiki.opensfs.org/Lustre_Working_Group> Lustre Working Group
o Wednesday, April 15: 2:00-3:30pm
OpenSFS LUG Planning Committee
3855 SW 153rd Drive Beaverton, OR 97003 USA
Phone: +1 503-619-0561 | Fax: +1 503-644-6708
Twitter: <https://twitter.com/opensfs> @OpenSFS
Email: <mailto:firstname.lastname@example.org> admin(a)opensfs.org | Website:
* Guest room rates are subject to applicable state and local taxes
(currently 13%) in effect at the time of check-out. Rooms will be offered
based on space and rate availability.
Open Scalable File Systems, Inc. was founded in 2010 to advance Lustre
development, ensuring it remains vendor-neutral, open, and free. Since its
inception, OpenSFS has been responsible for advancing the Lustre file system
and delivering new releases on behalf of the open source community. Through
working groups, events, and ongoing funding initiatives, OpenSFS harnesses
the power of collaborative development to fuel innovation and growth of the
Lustre file system worldwide.
This patchset attempts to fix the following issues catched by checkpatch:
trailing semicolons in macros
use of __attribute__(format(printf,...)) where __printf(...) would suffice
use of __attribute__(aligned(size)) where __aligned(size) would suffice
use of __attribute__(packed) where __packed would suffice
Mario J. Rugiero (4):
staging/lustre: checkpatch cleanup: macros should not use a trailing
staging/lustre: checkpatch cleanup: __printf(string-index,
first-to-check) is preferred over __attribute__((format(printf,
staging/lustre: checkpatch cleanup: __aligned(size) is preferred over
staging/lustre: checkpatch cleanup: __packed is preferred over
.../lustre/include/linux/libcfs/libcfs_debug.h | 6 +--
.../include/linux/libcfs/libcfs_kernelcomm.h | 4 +-
.../lustre/include/linux/libcfs/libcfs_private.h | 4 +-
.../staging/lustre/include/linux/lnet/lib-types.h | 2 +-
.../staging/lustre/lustre/include/lprocfs_status.h | 6 +--
drivers/staging/lustre/lustre/include/lu_object.h | 2 +-
.../lustre/lustre/include/lustre/lustre_idl.h | 44 +++++++++++-----------
.../lustre/lustre/include/lustre/lustre_user.h | 14 +++----
drivers/staging/lustre/lustre/include/lustre_dlm.h | 2 +-
drivers/staging/lustre/lustre/include/lustre_net.h | 2 +-
10 files changed, 43 insertions(+), 43 deletions(-)
We are about to set up a new Lustre system here, and we are trying to
decide between using 2.5.3 or 2.6.0 . Files in our older 2.1.6 system
will simply be migrated over, and the old system tossed down the tubes.
Is anyone using 2.6.0 in production? I found this on some 2.6.0
performance data, and it looks rather discouraging.
I have also noticed that the 2.5.3 server rpms actually use a slightly
newer kernel than the 2.6.0 set. By and large, we will use zfs
underlying the OST.
So, I will gladly accept any advice on which way we should turn as we
set this up.
I've come across an interesting quirk in the lustre startup script (/etc/init.d/lustre) when using zfs as the back end filesystem...
When I try to mount lustre using the service command I get the following error...
:~]# sudo service lustre start
Mounting lustre-ost0/ost0 on /ost0/lustre2-OST0000
mount.lustre: /lustre-ost0/ost0 has not been formatted with mkfs.lustre or the backend filesystem type is not supported by this tool
But it works without complaint if I run the mount script directly...
~]# /etc/init.d/lustre start
Mounting lustre-ost0/ost0 on /ost0/lustre2-OST0000
~]# df | grep lustre
lustre-ost0/ost0 105825194240 3456 105825188736 1% /ost0/lustre2-OST0000
Has anyone else seen this?
Kurt J. Strosahl
Scientific Computing Group, Thomas Jefferson National Accelerator Facility
Lately, one of our (12TB) OST jumped from ~50% to 100% capacity in a matter of hours.
We switched that OST to INACTIVE before it reached 100% but it kept filling, indicating an ongoing file write.
At the time it reached 100%, we got an ENOSPC on one of our client:
helvetix05: 2014-03-11 09:35:06 helvetix05 kernel: [1610930.474849] LustreError: 4431:0:(vvp_io.c:1022:vvp_io_commit_write()) Write page 1572607068 of inode ffff8800c96277c8 failed -28
helvetix05: 2014-03-11 09:35:06 helvetix05 kernel: [1610930.692143] LustreError: 4431:0:(vvp_io.c:1022:vvp_io_commit_write()) Write page 1572607068 of inode ffff8800c96277c8 failed -28
We tried to catch the run-away file using 'lfs find' but with a 250mio-files filesystem, this is no easy feat.
We also asked the suspected user, but he has no idea what/how things went wrong.
Can we assume the 1572607068 page figure point to a 6TB file (1572607068*4096 bytes) ?
(this would be consistent with the given OST capacity figures)
Is there a way to find which file corresponds to the ffff8800c96277c8 inode ?
Is there a way to perform the equivalent of the 'lfs find' directly on the MDS (e.g. by mounting the underlying ldiskfs) ?
Thanks for your help,
Cédric Dufour @ Idiap Research Institute
Phone: +41 27 721 77 40
Fax: +41 27 721 77 12
Mail: Idiap Research Institute
Case postale 592
Centre du Parc - Rue Marconi 19
1920 Martigny (VS)
Website: http://www.idiap.ch / http://www.idiap.ch/~cdufour <http://www.idiap.ch/%7Ecdufour>