public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] New distfile mirror layout
Date: Sun, 20 Oct 2019 11:44:33 +0200	[thread overview]
Message-ID: <af0bd84b058e8e7b7fcda092b1924f8fd272d87f.camel@gentoo.org> (raw)
In-Reply-To: <d6964a7b-e085-521b-dfba-f80b7985f414@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 2665 bytes --]

On Sun, 2019-10-20 at 05:21 -0400, Joshua Kinard wrote:
> On 10/20/2019 04:32, Michał Górny wrote:
> > On Sun, 2019-10-20 at 04:25 -0400, Joshua Kinard wrote:
> > > Why is having a max ~24k files in a directory a bad idea?  Modern
> > > filesystems are more than capable of handling that.
> > > 
> > >   - ext4: unlimited files in a directory
> > >   - xfs: virtually unlimited (hard limit of 2^64-1 total files per volume)
> > >   - ntfs: 4,294,967,295
> > > 
> > > And 24k is a bit more than 1/3rd of all distfiles that we currently have.
> > 
> > For the same reason having ~60k files in a directory was a problem. 
> > There is really no point in changing anything if you change BIG_NUMBER
> > to SMALLER_BIG_NUMBER.
> 
> That doesn't answer my question.  Why is it a problem?  What criteria are
> you using to decide that 24k is a "smaller big number"?  Is there some issue
> highlighted by the mirror admins where having 24k files in a single
> directory offers no significant relief versus the current 60k files?

IIRC Robin set the goal as:

| the number of files in a single directory should not exceed 1000, [1]

I don't recall how that number was chosen but it's probably pretty
arbitrary.  In any case, I can notice the difference between working
with a listing of 1k files and 24k files, on the hardware running
masterdist.

> > > Under which scenario do you wind up with 24k files in a single directory?  I
> > > consider the tex package an outlier in this case (one package should not be
> > > the sole dictator of policy).
> > 
> > Three versions of TeXLive living simultaneously.  If one package falls
> > completely out of bounds, no problem is solved by the change, so what's
> > the point of making it?
> 
> The problem in this case is with texlive, not our current, or future,
> distfiles methodology.

Is it?  Are you suggesting we should ban upstream from using multiple
distfiles with similar prefix?  What about other potential packages that
may suffer from the same problem in the future?  Go packages have a good
potential, given that majority of them starts with 'github.com'.

> Has anyone looked at how other distros deal with texlive?

Other distros don't mirror original distfiles.

>   Has anyone complained or filed a bug to texlive developers
> upstream about their excessive amount of distfiles and the burden it places
> on distro maintainers?

You believe it to be a problem.  Don't expect others to bother upstream
with your preferences.


[1] https://www.gentoo.org/glep/glep-0075.html#algorithm-for-splitting-distfiles

> 
-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

  reply	other threads:[~2019-10-20  9:44 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-18 13:41 [gentoo-dev] New distfile mirror layout Michał Górny
2019-10-18 19:53 ` Richard Yao
2019-10-18 20:49   ` Michał Górny
2019-10-19  1:09     ` Richard Yao
2019-10-19  6:17       ` Michał Górny
2019-10-19  8:20         ` Richard Yao
2019-10-19 19:26       ` Richard Yao
2019-10-19 20:02         ` Michał Górny
2019-10-19 22:48           ` Richard Yao
2019-10-22  0:46   ` James Cloos
2019-10-19 13:31 ` Fabian Groffen
2019-10-19 13:53   ` Michał Górny
2019-10-19 23:24 ` Joshua Kinard
2019-10-19 23:57   ` Alec Warner
2019-10-20  0:14     ` Joshua Kinard
2019-10-20  6:51   ` Michał Górny
2019-10-20  8:25     ` Joshua Kinard
2019-10-20  8:32       ` Michał Górny
2019-10-20  9:21         ` Joshua Kinard
2019-10-20  9:44           ` Michał Górny [this message]
2019-10-20 20:57             ` Joshua Kinard
2019-10-21  0:05               ` Joshua Kinard
2019-10-21  5:51                 ` Ulrich Mueller
2019-10-21 10:17                 ` Kent Fredric
2019-10-21 21:34                 ` Mikle Kolyada
2019-10-21 10:13               ` Kent Fredric
2019-10-23  5:16                 ` Joshua Kinard
2019-10-29 16:35                   ` Kent Fredric
2019-10-20 17:09       ` Matt Turner
2019-10-21 16:42     ` Richard Yao
2019-10-21 23:36       ` Matt Turner
2019-10-23  5:18         ` Joshua Kinard
2019-10-23 17:06           ` William Hubbs
2019-10-23 18:38             ` William Hubbs
2019-10-23 22:04           ` William Hubbs
2019-10-24  4:30             ` Michał Górny
2019-10-22  6:51       ` Jaco Kroon
2019-10-22  8:43         ` Ulrich Mueller
2019-10-22  8:46           ` Jaco Kroon
2019-10-23 23:47         ` ext4 readdir performance - was " Richard Yao
2019-10-24  0:01           ` Richard Yao
2019-10-23  1:21       ` Rich Freeman
2019-10-28 23:24     ` Chí-Thanh Christopher Nguyễn
2019-10-29  4:27       ` Michał Górny
2019-10-29  9:34         ` Fabian Groffen
2019-10-29 11:11           ` Michał Górny
2019-10-29 12:23             ` Ulrich Mueller
2019-10-29 12:43               ` Michał Górny
2019-10-29 13:03                 ` Ulrich Mueller
2019-10-29 13:09                   ` Ulrich Mueller
2019-10-29 13:52                     ` Michał Górny
2019-10-29 14:17                       ` Ulrich Mueller
2019-10-29 14:33                         ` Fabian Groffen
2019-10-29 14:45                           ` Michał Górny
2019-10-29 14:56                             ` Fabian Groffen
2019-10-29 13:51                   ` Michał Górny

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=af0bd84b058e8e7b7fcda092b1924f8fd272d87f.camel@gentoo.org \
    --to=mgorny@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox