similar to: Lustre 1.8 client on EL 6.5?

Hi, I tried to compile lustre-client 2.0.0.1 on RHEL4 with kernel 2.6.9-89.0.28.EL-x86_64 and I got 3 errors and 1 warning during the compile. The compile is executed with -Werror option, and it fails in all 4 cases * Error: lustre_compat25.h CC [M] /usr/src/redhat/BUILD/lustre-2.0.0.1/lustre/fid/fid_handler.o In file included from

Hi, Lustre manual 1.6 v18 says that that in production lustre debug level should be set to fairly low. Manual also says that I can verify that level by running following commands: # sysctl portals.debug This gives ne following error error: ''portals.debug'' is an unknown key cat /proc/sys/lnet/debug gives output: ioctl neterror warning error emerg ha config console cat

Hi, I get the following error when I try to mount lustre on the clients. Permanent disk data: Target: lustre-OSTffff Index: unassigned Lustre FS: lustre Mount type: ldiskfs Flags: 0x72 (OST needs_index first_time update ) Persistent mount opts: errors=remount-ro,extents,mballoc Parameters: mgsnode=164.107.119.231 at tcp sh: losetup: command not found mkfs.lustre: error 32512 on losetup:

Dear All, make[5]: Entering directory `/usr/src/kernels/2.6.23.15-80.fc7-x86_64'' /usr/src/redhat/BUILD/lustre-1.6.4.3/lustre/llite/lloop.c:142: warning: ''request_queue_t'' is deprecated /usr/src/redhat/BUILD/lustre-1.6.4.3/lustre/llite/lloop.c:273: warning: ''request_queue_t'' is deprecated /usr/src/redhat/BUILD/lustre-1.6.4.3/lustre/llite/lloop.c:312:

Hi Everyone, git noob. simple question, how do i get a previous release from jeremy''s git repository? Right now, I can get the latest (2.6.32.9) by doing the following: git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux-2.6-xen $ cd linux-2.6-xen $ git pull I tried doing a "git tag -l" when in linux-2.6-xen directory, but that did not print the tag

Hi Everyone, git noob. simple question, how do i get a previous release from jeremy''s git repository? Right now, I can get the latest (2.6.32.9) by doing the following: git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux-2.6-xen $ cd linux-2.6-xen $ git pull I tried doing a "git tag -l" when in linux-2.6-xen directory, but that did not print the tag

Hi, I''m seeing what can only be described as dismal striped write performance from lustre 1.6.3 clients :-/ 1.6.2 and 1.6.1 clients are fine. 1.6.4rc3 clients (from cvs a couple of days ago) are also terrible. the below shows that the OS (centos4.5/5) or fabric (gigE/IB) or lustre version on the servers doesn''t matter - the problem is with the 1.6.3 and 1.6.4rc3 client kernels

on our cluster that has been running lustre for about 1 month. I have 1 MDT/MGS and 1 OSS with 2 OST''s. Our cluster uses all Gige and has about 608 nodes 1854 cores. We have allot of jobs that die, and/or go into high IO wait, strace shows processes stuck in fstat(). The big problem is (i think) I would like some feedback on it that of these 608 nodes 209 of them have in dmesg

The race condition is noticed between disk_add() and disk attributes, on virtio-blk hotplug. Userspace listens to the KOBJ_ADD uevent generated in add_disk(). At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. As pointed out by Christoph Hellwig in the specific fix [1], virtio-blk

The race condition is noticed between disk_add() and disk attributes, on virtio-blk hotplug. Userspace listens to the KOBJ_ADD uevent generated in add_disk(). At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. As pointed out by Christoph Hellwig in the specific fix [1], virtio-blk

Hello, I have just setup a "toy" lustre setup using this guide here: http://zfsonlinux.org/lustre and have this process chewing 100% cpu. sh -c echo 0 >> /proc/fs/lustre/llite/lustre-ffff88006b0c7c00/max_cached_mb Until I get something more beasty I am using my desktop machine with KVM. Using standard Centos 6.4 with latest kernel. (2.6.32-358.23.2). my machine has 2GB ram Any

On 22 October 2013 16:21, Prakash Surya <surya1-i2BcT+NCU+M@public.gmane.org> wrote: > This probably belongs on the Lustre mailing list. I cross posted :) > Regardless, I don''t > think you want to do that (do you?). It''ll prevent any client side > caching, and more importantly, I don''t think it''s a case that''s been >

Hi, i just want to know whether there are any alternative file systems for HP SFS. I heard that there is Cluster Gateway from Polyserve. Can anybody plz help me in finding more abt this Cluster Gateway. Thanks and Regards, Ashok Bharat -----Original Message----- From: lustre-discuss-bounces at lists.lustre.org on behalf of lustre-discuss-request at lists.lustre.org Sent: Tue 2/12/2008 3:18 AM

More prep work for immutable biovecs - with immutable bvecs drivers won't be able to use the biovec directly, they'll need to use helpers that take into account bio->bi_iter.bi_bvec_done. This updates callers for the new usage without changing the implementation yet. Signed-off-by: Kent Overstreet <kmo at daterainc.com> Cc: Jens Axboe <axboe at kernel.dk> Cc: Geert

More prep work for immutable biovecs - with immutable bvecs drivers won't be able to use the biovec directly, they'll need to use helpers that take into account bio->bi_iter.bi_bvec_done. This updates callers for the new usage without changing the implementation yet. Signed-off-by: Kent Overstreet <kmo at daterainc.com> Cc: Jens Axboe <axboe at kernel.dk> Cc: Geert

More prep work for immutable biovecs - with immutable bvecs drivers won't be able to use the biovec directly, they'll need to use helpers that take into account bio->bi_iter.bi_bvec_done. This updates callers for the new usage without changing the implementation yet. Signed-off-by: Kent Overstreet <kmo at daterainc.com> Cc: Jens Axboe <axboe at kernel.dk> Cc: Geert

More prep work for immutable biovecs - with immutable bvecs drivers won't be able to use the biovec directly, they'll need to use helpers that take into account bio->bi_iter.bi_bvec_done. This updates callers for the new usage without changing the implementation yet. Signed-off-by: Kent Overstreet <kmo at daterainc.com> Cc: Jens Axboe <axboe at kernel.dk> Cc: Geert

More prep work for immutable biovecs - with immutable bvecs drivers won't be able to use the biovec directly, they'll need to use helpers that take into account bio->bi_iter.bi_bvec_done. This updates callers for the new usage without changing the implementation yet. Signed-off-by: Kent Overstreet <kmo at daterainc.com> Cc: Jens Axboe <axboe at kernel.dk> Cc: Geert

More prep work for immutable biovecs - with immutable bvecs drivers won't be able to use the biovec directly, they'll need to use helpers that take into account bio->bi_iter.bi_bvec_done. This updates callers for the new usage without changing the implementation yet. Signed-off-by: Kent Overstreet <kmo at daterainc.com> Cc: Jens Axboe <axboe at kernel.dk> Cc: Geert

Hello Folks, Are there client/server version combinations that would lead to read-only file systems on the client? We have 2.1.6.0 servers with 1.8.9 clients and it seems every 1.8.9 client just flips mounts to read-only (with no actual message until a write is attempted) yet when the OSSs (at 2.1.6.0) mount, they can write all day long. On write, the 1.8.9 clients log: LustreError: