Shawn Walker wrote:
On 08/17/12 14:34, Philip Brown wrote:
...
But then it goes and looks at the same files under the index, and
catalog, directories, of EVERY OTHER PUBLISHER
This is very wrong :(
I'm not sure where you get "wrong". A repository is not intended to be
a loose container that manages isolated sets of publisher data. Instead,
it is managed as a container that manages multiple sets of publisher data.
yes, right, great. Integrated whole, I can understand that. However, even in
integrated software entities, there is a benefit from modular design.
What part of this "multiple sets of data" approach, requires that an update
to one publisher area, then lead to even looking at any other publisher area
at all, let alone going through all the catalog and index files? This
violates modularity.
I might guess that the current locking mechanism is just a holdover from
when there was only a single publisher possible. Someone decided to do a
quick code refactor to allow subdirs/alt publishers, but didnt really think
about cleaning up the locking flow. Would that be the case?
In short, when a user points at a repository, some very minimal
validation of layout of the top level of each publisher and status is
necessarily performed to ensure that we don't use a repository that is
partially corrupt or invalid.
This does not follow, unless the whole system is horribly prone to
corruption, and unstable.
To my mind, a system that Solaris depends on reliably getting packages from,
should itself be reliable. As reliable as filesystem operations.
Yet in the filesystem realm, when I do "echo hi >$HOME/notes/today", the
filesystem does not seem to need to go through every other subdirectory in
my $HOME to avoid corruption of the $HOME dir.
The best way to avoid corruption of the top level, is to use locking at the
top level, when top level operations may have contention issues.
(and the best way to avoid corruption at sublevels, is to stay OUT of
sublevels if you have no business there!)
Yet for some reason, pkgrepo is using locking at the subdirectory level?
With NO top level locks, according to truss ? !
This is not good lock flow design, (coming from my experience with kernel
design, and also parallel scripting), which is why I wonder about this being
some legacy behaviour.
The behaviour that is there is intentional. That isn't to say that it
couldn't be changed, but in this particular case, the overhead of the
operations you saw should be very minimal unless you're severely I/O-bound.
Or unless you plan to have 100 separate publishers.
Which, for the record, I do.
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
