From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1S6NwQ-0001bG-J0 for garchives@archives.gentoo.org; Sat, 10 Mar 2012 15:10:43 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D9001E06CC; Sat, 10 Mar 2012 15:10:33 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) by pigeon.gentoo.org (Postfix) with ESMTP id 5CE3BE06CC for ; Sat, 10 Mar 2012 15:09:30 +0000 (UTC) Received: from mail-vx0-f181.google.com ([209.85.220.181]) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1S6NvI-0031kI-IL for gentoo-user@lists.gentoo.org; Sat, 10 Mar 2012 22:09:32 +0700 Received: by vcge1 with SMTP id e1so2946635vcg.40 for ; Sat, 10 Mar 2012 07:09:26 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.52.28.200 with SMTP id d8mr9641985vdh.38.1331392166305; Sat, 10 Mar 2012 07:09:26 -0800 (PST) Received: by 10.220.58.200 with HTTP; Sat, 10 Mar 2012 07:09:26 -0800 (PST) Received: by 10.220.58.200 with HTTP; Sat, 10 Mar 2012 07:09:26 -0800 (PST) In-Reply-To: <20120310143015.6d507af3@weird.wonkology.org> References: <20120310143015.6d507af3@weird.wonkology.org> Date: Sat, 10 Mar 2012 22:09:26 +0700 Message-ID: Subject: Re: [gentoo-user] Best file system for portage tree? From: Pandu Poluan To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=20cf3079bc9e211efa04bae4e5a4 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Archives-Salt: c393e6d7-2ac5-42c9-b7dd-8d2358153bac X-Archives-Hash: f31d206ab51eadec57542c741ae7c141 --20cf3079bc9e211efa04bae4e5a4 Content-Type: text/plain; charset=UTF-8 On Mar 10, 2012 8:33 PM, "Alex Schuster" wrote: > > Hi there! > > Is there an advantage in putting the portage tree on an extra partition? > > Currently, I'm using reiserfs, because I read that it is efficient when > using many small files. On the other hand I also heard that it tends to > get slower with every emerge --sync. > > Space is no longer an argument in these days, at least for my desktop > machine. But I would like to optimize for speed -- emerge -DputnVj > @world takes quite a while to calculate, I assume this is because so many > ebuild files have to be accessed. > > Any tips on this? Does it make sense to use a special file system just > for the portage tree? What would be best? Would it help to re-create this > file system from time to time in case it gets slower with every sync? Or > wouldn't I notice a difference if I just used a big ext4 partition for > all portage related stuff? > > Anyone using a compressed RAM file system for that? :) > This had been my burning question when I was deploying the company's production server, and forced me to do some research: * reiserfs is amazingly fast for reads, but suffers on simultaneous writes * reiserfs does not have inode limits * reiserfs' notail affects performance greatly depending on the nature of the system: I/O-bound (use notail) or CPU-bound (don't use notail) * reiserfs, if mounted without notail, is very space-efficient So, I end up with the following mix: * ext2 for /boot * reiserfs for /usr/portage and /var/tmp (RAM is at premium; can't use tmpfs) * ext4 for everything else This cocktail has been serving me well. I don't need advanced filesystems like ZFS, XFS, or btrfs, because my servers are virtualized, and the advanced features (e.g., snapshot) is handled by the underlying hypervisor (XenServer) and SAN Storage (we use NetApp). Rgds, --20cf3079bc9e211efa04bae4e5a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mar 10, 2012 8:33 PM, "Alex Schuster" <wonko@wonkology.org> wrote:
>
> Hi there!
>
> Is there an advantage in putting the portage tree on an extra partitio= n?
>
> Currently, I'm using reiserfs, because I read that it is efficient= when
> using many small files. On the other hand I also heard that it tends t= o
> get slower with every emerge --sync.
>
> Space is no longer an argument in these days, at least for my desktop<= br> > machine. But I would like to optimize for speed -- emerge -DputnVj
> @world takes quite a while to calculate, I assume this is because so m= any
> ebuild files have to be accessed.
>
> Any tips on this? Does it make sense to use a special file system just=
> for the portage tree? What would be best? Would it help to re-create t= his
> file system from time to time in case it gets slower with every sync? = Or
> wouldn't I notice a difference if I just used a big ext4 partition= for
> all portage related stuff?
>
> Anyone using a compressed RAM file system for that? :)
>

This had been my burning question when I was deploying the company's= production server, and forced me to do some research:

* reiserfs is amazingly fast for reads, but suffers on simultaneous writ= es
* reiserfs does not have inode limits
* reiserfs' notail affects performance greatly depending on the nature = of the system: I/O-bound (use notail) or CPU-bound (don't use notail) * reiserfs, if mounted without notail, is very space-efficient

So, I end up with the following mix:

* ext2 for /boot
* reiserfs for /usr/portage and /var/tmp (RAM is at premium; can't use = tmpfs)
* ext4 for everything else

This cocktail has been serving me well. I don't need advanced filesy= stems like ZFS, XFS, or btrfs, because my servers are virtualized, and the = advanced features (e.g., snapshot) is handled by the underlying hypervisor = (XenServer) and SAN Storage (we use NetApp).

Rgds,

--20cf3079bc9e211efa04bae4e5a4--