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 upgrad
> 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 re
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
Thanks.
On Fri, Aug 18, 2017 at 11:58 AM, Jones, Peter A
wrote:
> It should be out in the next few weeks. You can follow it shaping up at
> https://git.hpdd.intel.com/?p=fs/lustre-release.git;a=
> shortlog;h=refs/heads/b2_10
>
>
> On 8/17/17, 7:53 PM, "lustre-discuss o
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
http://lists.lustre.org/listin
u 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 did some testing before
> decid
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 wrote:
> On Fri, Jul 21, 2017 at 12:54:15PM +0800, Stu Midgley wrote:
> > Afternoon
> >
> > I have an MDS running on spinning medi
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 a
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 from the storage ar
"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, S
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
> file system' best practic
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 wrote:
> Hello,
>
> Is
t; >
>> >
>> > Permanent disk data:
>> > Target: test1-MDT
>> > Index: 0
>> > Lustre FS: test1
>> > Mount type: ldiskfs
>> > Flags: 0x105
>> > (MDT MGS writeconf )
>> > Persisten
g with 22 (Invalid argument)
>
>
>
>
> --
> Dr Stuart Midgley
> sdm...@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,
Extra, we are running 1.8.7
Thanks.
On Sat, Mar 17, 2012 at 5:10 PM, Stu Midgley 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
-- Forwarded message --
From: Stu Midgley
Date: Sat, Mar 17, 2012 at 5:10 PM
Subject: can't mount our lustre filesystem after tunefs.lustre --writeconf
To: wc-disc...@whamcloud.com
Afternoon
We have a rather severe problem with our lustre file system. We had a
full confi
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 node
argument
So... something futher up the chain doesn't like it as well.
On Tue, Aug 10, 2010 at 3:41 PM, Andreas Dilger
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
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
wrote:
> On 2010-08-10, at 01:20, Stu Midgley wrote:
>> # lctl pool_add l1.default l1-OST
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.
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 ha
nd started
> investigating and the file was fine.
>
> No, the file is never unlinked.
>
> How do I go about getting a lustre log?
>
>
> --
> Dr Stuart Midgley
> sdm...@gmail.com
>
>
>
> On 04/09/2009, at 11:28 PM, Oleg Drokin wrote:
>
>> Hello!
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:
1
Morning
We have seen 2 errors like
Jan 28 22:48:07 oss027 kernel: LDISKFS-fs error (device md2):
ldiskfs_init_inode_bitmap: Checksum bad for group 28718
Jan 28 22:48:07 oss027 kernel:
Jan 28 22:48:07 oss027 kernel: Remounting filesystem read-only
and then of course, that oss is hosed... we unmo
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 l
The idea for the fuse port came from using a CrayXT3 and seeing how
they link against liblustre before linking against the io routines
(open, close etc). In this way, you didn't have to change your code
to use liblustre. This lead me to thinking you could compile the
basic fuse mirror fs against
27 matches
Mail list logo
