Mike McGrath wrote: > Some of you have seen the disk alerts on app2, Looking more closely it > seems the host was not built with enough disk space (like was app1). So > after the freeze is over I'll rebuild it. > > It does raise a point about storage for transifex though. Basically each > host running transifex (or damned lies, I can't quite remember which) > keeps a local copy of every scm as part of its usage. For performance > reasons I don't think that will change but its something we'll want to > figure out long term. I haven't done the research but in my brain it > seems like running something like git/hg/svn/bzr over nfs will cause > problems. > I think the major thing is how the scms do locking. I know that bzr does its own locking in the pack-0.92 format and beyond that does not rely on os level locking (pack-0.92 is the default format in our currently deployed bzr). transifex should only be using subversion working trees which should be fine (although the documentation recomends to turn off subtree checking.) cvs, I'd imagine, would be similar to subversion. git and hg are unknown to me. > On the other hand, these aren't upstream repos but local cache so I'm also > curious what the harm would be, if they get borked one could just delete > the cache and it would repopulate. Thoughts? > I'll leave glezos to answer this. I think the problem area would be if a repository got into some sort of locked state that required us to manually remove it. -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
