Re: [lustre-devel] RFC: Spill device for Lustre OSD

Jinshan Xiong via lustre-devel <[email protected]> Tue, 4 Nov 2025 16:30:53 -0800
Newsgroups org.lustre.lists.lustre-devel
Message-ID <CAEp8vpg9GEq4wnrNk96=TwnHcA6SVzNyNH11KoLnaqciOrY6Ag@mail.gmail.com>
--===============7737040333725089555==
Content-Type: multipart/alternative; boundary="0000000000004b91270642ce1081"

--0000000000004b91270642ce1081
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 4, 2025 at 4:25=E2=80=AFPM Andreas Dilger <[email protected]> w=
rote:

>
> On Nov 4, 2025, at 4:54 PM, Jinshan Xiong <[email protected]> wrote:
> > On Tue, Nov 4, 2025 at 3:48=E2=80=AFPM Andreas Dilger <[email protected]=
a> wrote:
> >>
> >> If the overhead of a local Lustre mount on the OSS is problematic, tha=
t
> >> seems like something which could/should be fixed?  The local mounts ar=
e
> >> already "non-recoverable" so that they do not get an entry in last_rcv=
d
> >> and their absence does not cause any recovery issues.
> >>
> >> The main issue we've seen with local mountpoints is that this can
> confuse
> >> HA and prevent Lustre module unloading if they are not taken into
> account
> >> during cleanup.
> >
> > You're right. That's actually why we didn't do it in the first place. I=
f
> an OSS crashes, it will definitely lead to recovery timeout and client
> eviction.
>
> If an OSS crash with a local mountpoint is causing recovery timeouts,
> then that seems like a bug to be fixed.  This was changed by Alex Z.
> in patch "LU-12722 target: disable recovery for local clients" back in
> commit v2_13_52-45-g8bd04b4e57.
>

Thanks for the context. My knowledge of Lustre is many years old ;-)


>
> Cheers, Andreas
>
>
>
>
>
>

--0000000000004b91270642ce1081
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Nov 4, =
2025 at 4:25=E2=80=AFPM Andreas Dilger &lt;<a href=3D"mailto:adilger@dilger=
.ca">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><br>
On Nov 4, 2025, at 4:54 PM, Jinshan Xiong &lt;<a href=3D"mailto:jinshanx@go=
ogle.com" target=3D"_blank">[email protected]</a>&gt; wrote:<br>
&gt; On Tue, Nov 4, 2025 at 3:48=E2=80=AFPM Andreas Dilger &lt;<a href=3D"m=
ailto:[email protected]" target=3D"_blank">[email protected]</a>&gt; wrote:=
<br>
&gt;&gt; <br>
&gt;&gt; If the overhead of a local Lustre mount on the OSS is problematic,=
 that<br>
&gt;&gt; seems like something which could/should be fixed?=C2=A0 The local =
mounts are<br>
&gt;&gt; already &quot;non-recoverable&quot; so that they do not get an ent=
ry in last_rcvd<br>
&gt;&gt; and their absence does not cause any recovery issues.<br>
&gt;&gt; <br>
&gt;&gt; The main issue we&#39;ve seen with local mountpoints is that this =
can confuse<br>
&gt;&gt; HA and prevent Lustre module unloading if they are not taken into =
account<br>
&gt;&gt; during cleanup.<br>
&gt; <br>
&gt; You&#39;re right. That&#39;s actually why we didn&#39;t do it in the f=
irst place. If an OSS crashes, it will definitely lead to recovery timeout =
and client eviction.<br>
<br>
If an OSS crash with a local mountpoint is causing recovery timeouts,<br>
then that seems like a bug to be fixed.=C2=A0 This was changed by Alex Z.<b=
r>
in patch &quot;LU-12722 target: disable recovery for local clients&quot; ba=
ck in<br>
commit v2_13_52-45-g8bd04b4e57.<br></blockquote><div><br></div><div>Thanks =
for the context. My knowledge of Lustre is many years old ;-)</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Cheers, Andreas<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div></div>

--0000000000004b91270642ce1081--

--===============7737040333725089555==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
lustre-devel mailing list
[email protected]
http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org

--===============7737040333725089555==--