app2 disk space

[Toshio Kuratomi]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-infrastructure-list/attachments/20080919/0accce20/attachment.sig>