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 <gentoo-user+bounces-136082-garchives=archives.gentoo.org@lists.gentoo.org>) id 1S6O19-00029X-Fe for garchives@archives.gentoo.org; Sat, 10 Mar 2012 15:15:35 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 46399E08A5; Sat, 10 Mar 2012 15:15:22 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) by pigeon.gentoo.org (Postfix) with ESMTP id 12399E0720 for <gentoo-user@lists.gentoo.org>; Sat, 10 Mar 2012 15:14:21 +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 <pandu@poluan.info>) id 1S6O00-0033Ki-CX for gentoo-user@lists.gentoo.org; Sat, 10 Mar 2012 22:14:24 +0700 Received: by vcge1 with SMTP id e1so2951389vcg.40 for <gentoo-user@lists.gentoo.org>; Sat, 10 Mar 2012 07:14:18 -0800 (PST) Precedence: bulk List-Post: <mailto:gentoo-user@lists.gentoo.org> List-Help: <mailto:gentoo-user+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-user.gentoo.org> 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 d8mr9661147vdh.38.1331392458942; Sat, 10 Mar 2012 07:14:18 -0800 (PST) Received: by 10.220.58.200 with HTTP; Sat, 10 Mar 2012 07:14:18 -0800 (PST) Received: by 10.220.58.200 with HTTP; Sat, 10 Mar 2012 07:14:18 -0800 (PST) In-Reply-To: <CAA2qdGWYMk3-6jQJuT1jC0-j4WbvRD9TYFtDdu44OyZuooJMtA@mail.gmail.com> References: <20120310143015.6d507af3@weird.wonkology.org> <CAA2qdGWYMk3-6jQJuT1jC0-j4WbvRD9TYFtDdu44OyZuooJMtA@mail.gmail.com> Date: Sat, 10 Mar 2012 22:14:18 +0700 Message-ID: <CAA2qdGUGSKBM_Fz9p+N7rGj1ZKOM==gPCSvCGq4A9+iEEz-0aw@mail.gmail.com> Subject: Re: [gentoo-user] Best file system for portage tree? From: Pandu Poluan <pandu@poluan.info> To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=20cf3079bc9e92689504bae4f653 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: 3ff41cce-e9d0-4097-88a5-bc3ad56c2c95 X-Archives-Hash: 07af7a98948aa7307487fa295831bfa6 --20cf3079bc9e92689504bae4f653 Content-Type: text/plain; charset=UTF-8 On Mar 10, 2012 10:09 PM, "Pandu Poluan" <pandu@poluan.info> wrote: > > > 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 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, Okay, I did a mixup: If the system is I/O-bound, *don't* use notail (saves on disk read/write). If the system is CPU-bound, *use* notail (saves on having to 'unpack' the tail from the metadata). In my situation, the bottleneck is the SAN Storage, so I don't use notail. Rgds, --20cf3079bc9e92689504bae4f653 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p><br> On Mar 10, 2012 10:09 PM, "Pandu Poluan" <<a href=3D"mailto:pa= ndu@poluan.info">pandu@poluan.info</a>> wrote:<br> ><br> ><br> > On Mar 10, 2012 8:33 PM, "Alex Schuster" <<a href=3D"mail= to:wonko@wonkology.org">wonko@wonkology.org</a>> wrote:<br> > ><br> > > Hi there!<br> > ><br> > > Is there an advantage in putting the portage tree on an extra par= tition?<br> > ><br> > > Currently, I'm using reiserfs, because I read that it is effi= cient when<br> > > using many small files. On the other hand I also heard that it te= nds to<br> > > get slower with every emerge --sync.<br> > ><br> > > Space is no longer an argument in these days, at least for my des= ktop<br> > > machine. But I would like to optimize for speed -- emerge -DputnV= j<br> > > @world takes quite a while to calculate, I assume this is because= so many<br> > > ebuild files have to be accessed.<br> > ><br> > > Any tips on this? Does it make sense to use a special file system= just<br> > > for the portage tree? What would be best? Would it help to re-cre= ate this<br> > > file system from time to time in case it gets slower with every s= ync? Or<br> > > wouldn't I notice a difference if I just used a big ext4 part= ition for<br> > > all portage related stuff?<br> > ><br> > > Anyone using a compressed RAM file system for that? :)<br> > ><br> ><br> > This had been my burning question when I was deploying the company'= ;s production server, and forced me to do some research:<br> ><br> > * reiserfs is amazingly fast for reads, but suffers on simultaneous wr= ites<br> > * reiserfs does not have inode limits<br> > * reiserfs' notail affects performance greatly depending on the na= ture of the system: I/O-bound (use notail) or CPU-bound (don't use nota= il)<br> > * reiserfs, if mounted without notail, is very space-efficient<br> ><br> > So, I end up with the following mix:<br> ><br> > * ext2 for /boot<br> > * reiserfs for /usr/portage and /var/tmp (RAM is at premium; can't= use tmpfs) <br> > * ext4 for everything else<br> ><br> > This cocktail has been serving me well. I don't need advanced file= systems like ZFS, XFS, or btrfs, because my servers are virtualized, and th= e advanced features (e.g., snapshot) is handled by the underlying hyperviso= r (XenServer) and SAN Storage (we use NetApp).<br> ><br> > Rgds, </p> <p> Okay, I did a mixup:</p> <p>If the system is I/O-bound, *don't* use notail (saves on disk read/w= rite). </p> <p>If the system is CPU-bound, *use* notail (saves on having to 'unpack= ' the tail from the metadata).</p> <p>In my situation, the bottleneck is the SAN Storage, so I don't use n= otail. </p> <p>Rgds, <br> </p> --20cf3079bc9e92689504bae4f653--