You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Sinang, Danny" <D....@spi-bpo.com> on 2006/05/17 04:34:59 UTC

Maximum number of subdirectories

Hello,
 
I'm thinking of creating 1 repository for each article to keep the
revision number to a reasonable level. 
 
Since we've got hundreds of thousands of articles, I'm concerned I might
hit a maximum number of subdirectories if I store all repositories under
one directory.
 
We'll be using either ReiserFS or Reiser4. Anybody here know the max
subdir limits of these filesystems ?
 
How about for JFS, XFS, or EXT3 ?
 
Regards,
Danny 
 
 
 
 

Re: Maximum number of subdirectories

Posted by Nico Kadel-Garcia <nk...@comcast.net>.
There's an old limit with ext2 and ext3 before the 2.6 kernel: more than a few thousand subdirectories caused problems for anything that had to "stat" the master directory. But that problem went away with the 2.6 kernel, and I actually prefer ext3 to reiserfs because I find ext3 behaves better when your hardware starts failing.
  ----- Original Message ----- 
  From: Sinang, Danny 
  To: users@subversion.tigris.org 
  Sent: Wednesday, May 17, 2006 12:34 AM
  Subject: Maximum number of subdirectories


  Hello,

  I'm thinking of creating 1 repository for each article to keep the revision number to a reasonable level. 

  Since we've got hundreds of thousands of articles, I'm concerned I might hit a maximum number of subdirectories if I store all repositories under one directory.

  We'll be using either ReiserFS or Reiser4. Anybody here know the max subdir limits of these filesystems ?

  How about for JFS, XFS, or EXT3 ?

  Regards,
  Danny 




Plots of commits to repositories

Posted by Alejandro Forero Cuervo <az...@bachue.com>.
Hi.

I wrote some code calling libsvn_client to plot statistics of commits
to repositories.  You can see it working for some public free software
repositories here:

  http://freaks-unidos.net/svn-graph/

I update the graphs every day.

All the code required to generate these plots is free software.  There
is a little bit of documentation here:

  http://wiki.freaks-unidos.net/svn-graph

Plots for Subversion's own repository is available here:

  http://freaks-unidos.net/svn-graph/subversion/

If you know of other relatively high-profile free software
repositories, please let me know so I can add them to the list of
repositories for which I generate plots.

Any suggestions are welcome.

I hope you find this useful.

Alejo.
http://azul.freaks-unidos.net/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Maximum number of subdirectories

Posted by "B. Smith-Mannschott" <be...@gmail.com>.
On May 17, 2006, at 06:34, Sinang, Danny wrote:
Hello,

I'm thinking of creating 1 repository for each article to keep the  
revision number to a reasonable level.


Huh? Why?

The revision number does nothing more than count the number of  
modifications to the repository. If it bothers you then ignore it. It  
hardly seems worth the overhead (in effort and space) of maintaining  
thousands of repositories just so that you can keep your revision  
numbers "reasonable".  If you want to keep track of particular  
versions of articles, consider using tags (see the subversion book).


Since we've got hundreds of thousands of articles, I'm concerned I  
might hit a maximum number of subdirectories if I store all  
repositories under one directory.

We'll be using either ReiserFS or Reiser4. Anybody here know the max  
subdir limits of these filesystems ?

How about for JFS, XFS, or EXT3 ?

EXT3 is the only file system where I'd worry about performance of  
very large directories. (but see above).

// ben

p.s. You wrote yesterday asking what to do about a disk that's  
getting full. Creating thousands of repositories is a good way to  
make sure the disk fills up even faster. (After all, there's a  
certain fixed cost beyond the actual contents for every repository).