[Lustre-discuss] user space lustre

2008-05-22 Thread Stu Midgley
Evening Just wondering if the user-space port of lustre servers to Solaris/ZFS will have normal fs caching, or will they do direct IO? That is, the lustre servers will effectively get caching simply by being in user space. We have an application that would significantly benefit from caching on

[Lustre-discuss] inode weirdness

2009-09-04 Thread Stu Midgley
I am having jobs on a cluster client crash. The job creates a small text file (using cp) and then immediately tries to use it with another application. The application fails saying the file doesn't exist. In the client /var/log/messages, I'm seeing Sep 4 15:58:17 clus039 kernel: LustreError:

Re: [Lustre-discuss] Future of LusterFS?

2010-04-23 Thread Stu Midgley
We run lustre on cheap off the shelf gear. We have 4 generations of cheapish gear in a single 300TB lustre config (40 oss's) It has been running very very well for about 3.5 years now. Would lustre have issues if using cheap off the shell components or would people here think you need to

Re: [Lustre-discuss] ost pools

2010-08-09 Thread Stu Midgley
no, that didn't help at all. # lctl pool_add l1.default l1-OST[10] OST l1-OST0010_UUID is not part of the 'l1' fs. pool_add: No such file or directory All the nodes that have the new-style names went into the pool just fine. all the nodes with old-style names will not go into the pool. eg.

Re: [Lustre-discuss] ost pools

2010-08-10 Thread Stu Midgley
Right, so I assume this means it will be fixed in some future version of lustre and until then I can't have those nodes in the pool until then? On Tue, Aug 10, 2010 at 3:41 PM, Andreas Dilger andreas.dil...@oracle.com wrote: On 2010-08-10, at 01:20, Stu Midgley wrote: # lctl pool_add l1

Re: [Lustre-discuss] ost pools

2010-08-15 Thread Stu Midgley
argument So... something futher up the chain doesn't like it as well. On Tue, Aug 10, 2010 at 3:41 PM, Andreas Dilger andreas.dil...@oracle.com wrote: On 2010-08-10, at 01:20, Stu Midgley wrote: # lctl pool_add l1.default l1-OST[10] OST l1-OST0010_UUID is not part of the 'l1' fs. pool_add

[Lustre-discuss] 1.8.4 and write-through cache

2010-09-13 Thread Stu Midgley
Afternoon I upgraded our oss's from 1.8.3 to 1.8.4 on Saturday (due to https://bugzilla.lustre.org/show_bug.cgi?id=22755) and suffered a great deal of pain. We have 30 oss's of multiple vintages. The basic difference between them is * md on first 20 nodes * 3ware 9650SE ML12 on last 10

Re: [Lustre-discuss] can't mount our lustre filesystem after tunefs.lustre --writeconf

2012-03-17 Thread Stu Midgley
Extra, we are running 1.8.7 Thanks. On Sat, Mar 17, 2012 at 5:10 PM, Stu Midgley sdm...@gmail.com wrote: Afternoon We have a rather severe problem with our lustre file system.  We had a full config log and the advice was to rewrite it with a new one.  So, we unmounted our lustre file

Re: [Lustre-discuss] [wc-discuss] can't mount our lustre filesystem after tunefs.lustre --writeconf

2012-03-17 Thread Stu Midgley
...@gmail.com On 18/03/2012, at 12:17 AM, Nathan Rutman wrote: Take them all down again, use tunefs.lustre --force --fsname. On Mar 17, 2012, at 2:10 AM, Stu Midgley sdm...@gmail.com wrote: Afternoon We have a rather severe problem with our lustre file system.  We had a full config log

Re: [Lustre-discuss] [wc-discuss] can't mount our lustre filesystem after tunefs.lustre --writeconf

2012-03-18 Thread Stu Midgley
:20 AM, Stu Midgley sdm...@gmail.com wrote: ok, from what I can tell, the root of the problem is [root@mds001 CONFIGS]# hexdump -C p1-MDT  | grep -C 2 mds 2450  0b 00 00 00 04 00 00 00  12 00 00 00 00 00 00 00  || 2460  70 31 2d 4d 44 54 30 30  30 30 00 00 00

Re: [lustre-discuss] Lustre on mac os 10.10 and windows 7

2015-08-05 Thread Stu Midgley
In some sense their has already been a port of Lustre to macosx and windows. I ported it using FUSE about 10years ago, using liblustre. It was about a 10min exercise... I have absolutely no idea where liblustre is at now... On Wed, Aug 5, 2015 at 8:36 PM, Michaël Parchet mparc...@sunrise.ch

Re: [lustre-discuss] Why certain commands should not be used on Lustre file system

2016-02-09 Thread Stu Midgley
We actually use find -type f -print0 | xargs -n 100 -P 32 -0 -- rm -f which will parallelise the rm... which runs a fair bit faster. On Wed, Feb 10, 2016 at 3:33 PM, wrote: > Hi, > > Then rm -rf * should not be used in any kind of file system. Why only Lustre

Re: [lustre-discuss] Error Lustre/multipath/storage

2016-03-28 Thread Stu Midgley
upgrade your IS5600 firmware. We were seeing this till we upgraded to the latest NetApp firmware. On Mon, Mar 28, 2016 at 10:30 PM, Ben Evans wrote: > You're getting multipathing errors, which means it's most likely not a > filesystem-level issue. See if you can get the logs

Re: [lustre-discuss] Error Lustre/multipath/storage

2016-03-28 Thread Stu Midgley
"rdac" failback "immediate" rr_weight "uniform" no_path_retry 30 retain_attached_hw_handler "yes" detect_prio "yes" } } On Mon, Mar 28, 2016 at 11:23 PM, Stu

[lustre-discuss] backup zfs MDT or migrate from ZFS back to ldiskfs

2017-07-20 Thread Stu Midgley
Afternoon I have an MDS running on spinning media and wish to migrate it to SSD's. Lustre 2.9.52 ZFS 0.7.0-rc3 How do I do it? This is a loaded question :) The MDT is using ~2TB of space. I used the zfs send | zfs receive method to no avail. It was just too slow (I killed it after

Re: [lustre-discuss] backup zfs MDT or migrate from ZFS back to ldiskfs

2017-07-20 Thread Stu Midgley
we have been happily using 2.9.52+0.7.0-rc3 for a while now. The MDT is a raidz3 across 4 disks. On Fri, Jul 21, 2017 at 1:19 PM, Isaac Huang <he.hu...@intel.com> wrote: > On Fri, Jul 21, 2017 at 12:54:15PM +0800, Stu Midgley wrote: > > Afternoon > > > > I have an MD

Re: [lustre-discuss] backup zfs MDT or migrate from ZFS back to ldiskfs

2017-07-22 Thread Stu Midgley
Stu, > Is there a reason why you picked Raidz 3 rather than 4 way mirror across 4 > disks? > Raidz 3 parity calculation might take more cpu resources rather than > mirroring across disks but also the latency may be higher in mirroring to > sync across all the disks. Wondering if you

[lustre-discuss] lustre 2.10.1 eta?

2017-08-17 Thread Stu Midgley
Morning Any eta on when lustre 2.10.1 might land? We are especially keen to get LU-9305 in a tested release. Thanks. -- Dr Stuart Midgley sdm...@gmail.com ___ lustre-discuss mailing list lustre-discuss@lists.lustre.org

Re: [lustre-discuss] lustre 2.10.1 eta?

2017-08-17 Thread Stu Midgley
7:53 PM, "lustre-discuss on behalf of Stu Midgley" < > lustre-discuss-boun...@lists.lustre.org on behalf of sdm...@gmail.com> > wrote: > > Morning > > Any eta on when lustre 2.10.1 might land? We are especially keen to get > LU-9305 in a tested release. > > T

Re: [lustre-discuss] Announce: Lustre Systems Administration Guide

2017-11-17 Thread Stu Midgley
Thank you both for the documentation. I know how hard it is to maintain. I've asked that all my admin staff to read it - even if some of it doesn't directly apply to our environment. What we would like is ell organised, comprehensive, accurate and up to date documenation. Most of the time when

Re: [lustre-discuss] corrupt FID on zfs?

2018-04-09 Thread Stu Midgley
> Try it with the last field as 0x0, like "[0x20a48:0x1e86e:0x0]". > On the OST, we use the last field to store the stripe index for the file, > so that LFSCK can reconstruct the file layout even if the MDT inode is > corrupted. OK, thanks. Setting it to 0x0 worked and returned No such

[lustre-discuss] corrupt FID on zfs?

2018-04-09 Thread Stu Midgley
Afternoon We have copied off all the files from an OST (lfs find identifies no files on the OST) but the OST still has some left over files eg. 9.6G O/0/d22/1277942 when I get the FID of this file using zfsobj2fid it appears to get a corrupt FID [0x20a48:0x1e86e:0x1] which then

Re: [lustre-discuss] Upgrade without losing data from 1.8.6 to 2.5.2 and back if necessary

2019-02-05 Thread Stu Midgley
We did an upgrade from 1.8.# to 2.5 and 2.7 about 2 years ago... all went smoothly. Good luck :) On Mon, Feb 4, 2019 at 10:26 AM Patrick Farrell wrote: > Wow, 1.8 is pretty old these days, as is 2.5 (first release 6 years > ago!). I hope you're planning on upgrading past 2.5 once you've