Date: Fri, 30 Sep 2022 15:52:03 -0400 From: Paul Procacci <pprocacci@gmail.com> To: Aryeh Friedman <aryeh.friedman@gmail.com> Cc: "Steve O'Hara-Smith" <steve@sohara.org>, "freebsd-questions@freebsd.org" <questions@freebsd.org> Subject: Re: mkdir error message -- what does this mean? Message-ID: <CAFbbPuhsQNT%2Bq3cepXnYqgt%2BqbE7T3kC=ei0OGbz-ncq0QMXhg@mail.gmail.com> In-Reply-To: <CAGBxaXmPZmnbg0FPcov5dfB-rPaKO2eN=0bLgtSqHQCRACEf_w@mail.gmail.com> References: <e293b9c3b1c168ad1eee3a65510b1aa9@nyclocal.net> <CAGBxaXnc_ornipZxX=NgoDagCjcU80vMXZ1EjZr8j-8RrcdJnw@mail.gmail.com> <CAFbbPuhXUqwcq%2BKsdD=q6C-w6JcypZLMKJGb9vUGp2k8r=G3=Q@mail.gmail.com> <20220930200244.31d71c489812fd26c0d39769@sohara.org> <CAGBxaXmPZmnbg0FPcov5dfB-rPaKO2eN=0bLgtSqHQCRACEf_w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000a1c70105e9ea5455 Content-Type: text/plain; charset="UTF-8" Hey Aryeh, You can still retain the files, but you just need to organize them in a fashion in which the parent (or otherwise) doesn't reach the limit. I'd suggest the easiest way is organizing them by year or even going a bit more fine tuned like parent/year/month/day ... or maybe even parent/archive/year/month ... or .... you get the idea. There are many ways to skin this cat. Regardless of what you decide, you now know there's a limit and can conceivably determine the best way of fixing it. ;) Thanks, Paul Procacci On Fri, Sep 30, 2022 at 3:21 PM Aryeh Friedman <aryeh.friedman@gmail.com> wrote: > On Fri, Sep 30, 2022 at 3:03 PM Steve O'Hara-Smith <steve@sohara.org> > wrote: > > > > On Fri, 30 Sep 2022 14:48:09 -0400 > > Paul Procacci <pprocacci@gmail.com> wrote: > > > > > 31 EMLINK Too many links. Maximum allowable hard links to a single > > > file has been exceeded (limit of 32767 hard links per file). > > > > > > I betcha the parent directory has at least this many number of objects > in > > > it. > > > > DIRHASH has a lot to answer for, time was we'd jump through hoops > > when writing applications to avoid having huge numbers of files in a > > directory, now nobody notices any problems until they hit the limit. > > To make matters worse many modern apps have a legal requirement to > retain files. The offending app is a medical records system that has > a minimal retention requirements for most of the files of 18 months > and some files as long as 7 years (the offending files where in the > second category since they are the "physical" proscription from a > doctor [the system has several hundred doctors spread over 50 or so > orgs). Note it took 8 years of moderate to heavy use to hit this > limit and it was only because we never wrote any code to delete > emptied out dirs. > > > > -- > > Steve O'Hara-Smith <steve@sohara.org> > > > > > -- > Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org > > -- __________________ :(){ :|:& };: --000000000000a1c70105e9ea5455 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hey Aryeh,</div><div><br></div><div>You can still ret= ain the files, but you just need to organize them in a fashion in which the= parent (or otherwise) doesn't reach the limit.<br></div><div>I'd s= uggest the easiest way is organizing them by year or even going a bit more = fine tuned like parent/year/month/day ... or maybe even parent/archive/year= /month ... or .... you get the idea.=C2=A0 There are many ways to skin this= cat.<br>Regardless of what you decide, you now know there's a limit an= d can conceivably determine the best way of fixing it.=C2=A0 ;)<br></div><d= iv><br></div><div>Thanks,</div><div>Paul Procacci<br></div></div><br><div c= lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Sep 30, = 2022 at 3:21 PM Aryeh Friedman <<a href=3D"mailto:aryeh.friedman@gmail.c= om">aryeh.friedman@gmail.com</a>> wrote:<br></div><blockquote class=3D"g= mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204= ,204,204);padding-left:1ex">On Fri, Sep 30, 2022 at 3:03 PM Steve O'Har= a-Smith <<a href=3D"mailto:steve@sohara.org" target=3D"_blank">steve@soh= ara.org</a>> wrote:<br> ><br> > On Fri, 30 Sep 2022 14:48:09 -0400<br> > Paul Procacci <<a href=3D"mailto:pprocacci@gmail.com" target=3D"_bl= ank">pprocacci@gmail.com</a>> wrote:<br> ><br> > >=C2=A0 =C2=A0 =C2=A0 31 EMLINK Too many links. Maximum allowable h= ard links to a single<br> > > file has been exceeded (limit of 32767 hard links per file).<br> > ><br> > > I betcha the parent directory has at least this many number of ob= jects in<br> > > it.<br> ><br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DIRHASH has a lot to answer for, time= was we'd jump through hoops<br> > when writing applications to avoid having huge numbers of files in a<b= r> > directory, now nobody notices any problems until they hit the limit.<b= r> <br> To make matters worse many modern apps have a legal requirement to<br> retain files.=C2=A0 The offending app is a medical records system that has<= br> a minimal retention requirements for most of the files of 18 months<br> and some files as long as 7 years (the offending files where in the<br> second category since they are the "physical" proscription from a= <br> doctor [the system has several hundred doctors spread over 50 or so<br> orgs).=C2=A0 Note it took 8 years of moderate to heavy use to hit this<br> limit and it was only because we never wrote any code to delete<br> emptied out dirs.<br> ><br> > --<br> > Steve O'Hara-Smith <<a href=3D"mailto:steve@sohara.org" target= =3D"_blank">steve@sohara.org</a>><br> ><br> <br> <br> -- <br> Aryeh M. Friedman, Lead Developer, <a href=3D"http://www.PetiteCloud.org" r= el=3D"noreferrer" target=3D"_blank">http://www.PetiteCloud.org</a><br>; <br> </blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr" class=3D"g= mail_signature">__________________<br><br>:(){ :|:& };:</div> --000000000000a1c70105e9ea5455--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFbbPuhsQNT%2Bq3cepXnYqgt%2BqbE7T3kC=ei0OGbz-ncq0QMXhg>