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 <<a href=3D"mailto:adilger@dilger= .ca">[email protected]</a>> 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 <<a href=3D"mailto:jinshanx@go= ogle.com" target=3D"_blank">[email protected]</a>> wrote:<br> > On Tue, Nov 4, 2025 at 3:48=E2=80=AFPM Andreas Dilger <<a href=3D"m= ailto:[email protected]" target=3D"_blank">[email protected]</a>> wrote:= <br> >> <br> >> If the overhead of a local Lustre mount on the OSS is problematic,= that<br> >> seems like something which could/should be fixed?=C2=A0 The local = mounts are<br> >> already "non-recoverable" so that they do not get an ent= ry in last_rcvd<br> >> and their absence does not cause any recovery issues.<br> >> <br> >> The main issue we've seen with local mountpoints is that this = can confuse<br> >> HA and prevent Lustre module unloading if they are not taken into = account<br> >> during cleanup.<br> > <br> > You're right. That's actually why we didn'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 "LU-12722 target: disable recovery for local clients" 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==--