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
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:
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
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.
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
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
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
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
...@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
: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
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
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
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
"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
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
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
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
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
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
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
> 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
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
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
23 matches
Mail list logo