On 08/17/12 15:07, Philip Brown wrote:
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?
No. Again, this is not about the locking.
Please reference the design document for the current repository format:
http://src.opensolaris.org/source/xref/pkg/gate/doc/on-disk-format.txt
The top-level of the repository is intended to be able to hold a shared
file storage area that crosses publisher boundaries to reduce storage
requirements for specific use cases.
The pkg5.repository file itself is intended to contain metadata that can
drive both pkg.depotd and potentially client behaviour as a whole, so is
necessarily centralised instead of per-publisher.
The fact that a particular path was encountered where locking is
preventing a specific use case is not the issue here.
...
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.
Many individuals would be surprised at the sorts of things
administrators or developers do to a repository that has nothing to do
with the OS or filesystem that can cause issues. An intentional choice
was made to insist on the repository (as a whole) being in a valid state
upon use.
...
Yet for some reason, pkgrepo is using locking at the subdirectory level?
With NO top level locks, according to truss ? !
pkgrepo does not maintain the locking itself. (This is a nitpick.) The
Repository class is itself responsible for all locking operations based
on operations being performed. As I mentioned before, clients do not
maintain the locks nor determine how locking will be done.
...
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.
As I said before, there is currently no intention or provision for
delegating management of a repository to separate users and the system
is designed to expect a single user to manage a repository.
As a whole, the system is not currently intended nor designed for the
usage case described here. However, the use case described here has
already been captured in existing RFEs and will be evaluated in the future.
At this time, I have no further guidance to provide.
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
