similar to: lustre-1.8 OSD

hello, does lustre support OSD T10 standard? Can it be used with IBM''s/Intel''s OSD initiator and target? Thanks, Ashish -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.lustre.org/pipermail/lustre-discuss/attachments/20071128/c2de31a6/attachment-0002.html

Hi everyone, I have seen this question here before, but without a very satisfactory answer. One of our half a dozen clients has lost access to a set of OSTs: > lfs osts OBDS:: 0: lustre-OST0000_UUID ACTIVE 1: lustre-OST0001_UUID ACTIVE 2: lustre-OST0002_UUID INACTIVE 3: lustre-OST0003_UUID INACTIVE 4: lustre-OST0004_UUID INACTIVE 5: lustre-OST0005_UUID ACTIVE 6: lustre-OST0006_UUID ACTIVE

We are seeing some disturbing (probably due to our ignorance) behavior from lustre 1.6.3 right now. We have 8 OSSs with 3 OSTs per OSS (24 physical LUNs). We just created a brand new lustre file system across this configuration using the default mkfs.lustre formatting options. We have this file system mounted across 400 clients. At the moment, we have 63 IOzone threads running

Dear r-helpers, Can anyone suggest why lm() doesn't complain here: summary(osss.lm1 <- lm(logOdds ~ c.setSize %in% task, data = osss)) whereas in package:nlme (and in package:lme4) osss.lmL <- lmList(logOdds ~ c.setSize %in% task | subj, data = osss) # Error in `contrasts<-`(`*tmp*`, value = "contr.treatment") : # contrasts can be applied only to factors with 2 or more

Hi, A bit of explanation of what I''m trying to achieve : We have a bunch of homogeneous nodes that have CPU + RAM + Storage and we want to use that as some generic cluster. The idea is to have Xen on all of these and run Ceph OSD in a domU on each to "export" the local storage space to the entire cluster. And then use RBD to store / access VM images from any of the machines.

Chris, Perhaps you need to perform some write_conf like command. I''m not sure if this is needed in 1.6 or not. Shane ----- Original Message ----- From: lustre-discuss-bounces at lists.lustre.org <lustre-discuss-bounces at lists.lustre.org> To: lustre-discuss <lustre-discuss at lists.lustre.org> Sent: Fri Mar 07 12:03:17 2008 Subject: Re: [Lustre-discuss] Multihomed

Our current Lustre servers run the version 1.8.1.1 with the regular ldiskfs. We are looking to expand our Lustre file system with new servers/storage and upgrade to all the lustre servers to 1.8.4 as well at the same time. We would like to make use of the ldiskfs-ext4 on the new servers to use larger OSTs. I just want to confirm the following facts: 1. Is is possible to run different versions

Hello Lustre Experts I am trying to solve a problem with very slow "ls" and other big amount of file operations but good overall read/write rates. We are running a small cluster of 3 OSSs with 9 OSTs, 1MDS (with SSD MDT) and currently two clients. All server nodes are centos 5.2 with lustre 1.8.1 while the clients are centos 5.4 with lustre 1.8.3. All components are networked with DDR

I recently started using compiz-fusion. After spending months looking at an anemic little rectangular on-screen volume control when I use the volume buttons on my ubuntu thinkpad T60p, all of a sudden I noticed that I was getting a nice, big, robust rounded-corner display (somewhat mac-like). Now it's gone again. I really have no clue whether this came from compiz-fusion, emerald, a plugin,

Hi, With help from Oleg we got the right patches applied and NFS working well. Maximum performance was about 60 MB/sec. Last week that dropped to about 12.5 MB/sec and I cannot find a reason. Lustre clients all obtain 100+ MB/sec on GigE. Each OST is good for 270 MB/sec. When mounting the client on one of the OSSs I get 230 MB/sec. Seems the speed is there. How can NFS and Lustre be tuned

The OSD layer was a wrapper around native interfaces adding little value and was infact buggy - refer to the osd_wait.patch for details. This patch gets rid of the OSD abstraction. Signed-off-by: K. Y. Srinivasan <kys at microsoft.com> Signed-off-by: Hank Janssen <hjanssen at microsoft.com> --- drivers/staging/hv/Makefile | 2 +- drivers/staging/hv/blkvsc.c | 2 +-

The OSD layer was a wrapper around native interfaces adding little value and was infact buggy - refer to the osd_wait.patch for details. This patch gets rid of the OSD abstraction. Signed-off-by: K. Y. Srinivasan <kys at microsoft.com> Signed-off-by: Hank Janssen <hjanssen at microsoft.com> --- drivers/staging/hv/Makefile | 2 +- drivers/staging/hv/blkvsc.c | 2 +-

Hi, I have high IO-Wait on the ods (ceph), the osd are running a v3.1-rc9 kernel. I also experience high IO-rates, around 500IO/s reported via iostat. Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 0.00 0.00 6.80 0.00 62.40 18.35 0.04 5.29 0.00 5.29 5.29 3.60 sdb

Hi, I''ve a quad-core x86_64 machine (Intel Xeon), with sse/mmx support. However, I want to disable sse/mmx support from HVM guests. How can I do this? Also, is it reasonable to expect illegal instruction fault in non-root VMX mode if a guest VM runs an application with sse/mmx instructions? Thanks, Ashish _______________________________________________ Xen-devel mailing list

does that mean .o generated with gcc (.c -> .s and .s -> .o) will not contain llvm ir? i meant, final kernel bitcode ir arch independent and can be JIT with any arch-specific backend. Is it not the case? thanks, ashish On Sat, Sep 27, 2008 at 10:43 PM, Andrew Lenharth <andrewl at lenharth.org> wrote: > On Sat, Sep 27, 2008 at 8:08 PM, Ashish Bijlani > <ashish.bijlani at

Hi all, I am a grad student at Carnegie Mellon University. I had my course work in advanced storage systems in previous semester, and I am interested to work on Lustre. I prefer to take up a project that could be completed in a duration of a month or two. Since I am a novice w.r.t. my familiarity with Lustre code base, I seek your opinion to choose a project from the list:

No, this is not the case. Just because you compile something to LLVM IR does not make the thing you compiled work on every architecture. You may even be able to retarget it to any architecture (it depends), but this in no way means the result will *actually work*. The LLVM IR generated by llvm-gcc is very architecture dependent. Theoretically you could make a C compiler that was mostly C

I am trying to compile lustre like this : [onkar at localhost build-lustre]$ ./configure --with-kernel-source-header=/home/onkar/LUSTRE/linux-2.6.33.3/include --with-linux=/home/onkar/LUSTRE/linux-2.6.33.3 --with-linux-obj=/home/onkar/LUSTRE/linux-2.6.33.3 --with-linux-config=/home/onkar/LUSTRE/linux-2.6.33.3 checking build system type... i686-pc-linux-gnu checking host system type...

I am trying to compile lustre like this : [onkar at localhost build-lustre]$ ./configure --with-kernel-source-header=/home/onkar/LUSTRE/linux-2.6.33.3/include --with-linux=/home/onkar/LUSTRE/linux-2.6.33.3 --with-linux-obj=/home/onkar/LUSTRE/linux-2.6.33.3 --with-linux-config=/home/onkar/LUSTRE/linux-2.6.33.3 checking build system type... i686-pc-linux-gnu checking host system type...

This got me closer, but it got to "Encapsulating winpe.wim..." and never went through the rest of the way. Ultimately PXELINUX apparently timed out and the machine rebooted. Here is relative portion of pxelinux: LABEL SCCM OSD Boot MENU LABEL ^2. SCCM OSD Boot com32 linux.c32 append wimboot initrdfile=bootmgr.exe,BCD,boot.sdi,winpe.wim TEXT HELP