Date: Fri, 13 Jan 2006 07:04:02 -0600 From: Eric Anderson <anderson@centtech.com> To: Patrik Forsberg <patrik.forsberg@dataphone.net> Cc: freebsd-isp@freebsd.org, Alexander <shulik_freebsd@matrixhome.net> Subject: Re: FreeBSD as Server Message-ID: <43C7A542.6080303@centtech.com> In-Reply-To: <375DD163B075E34EA3C10A6286E34A54C1D4D1@exhsto1.se.dataphone.com> References: <375DD163B075E34EA3C10A6286E34A54C1D4D1@exhsto1.se.dataphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Patrik Forsberg wrote: >>> UFS2 scales very well on a havy loaded server so I see no >>> >> reason to use >> >>> RaiserFS or any other FS in FreeBSD ? >>> >> One good reason, would be journaling, but that isn't >> necessarily compelling. >> > > true, true! > But aint GEOM journalling coming ? and I saw something about > UFS2-journalling(something like ext3) too ? but those are both in > development so.. still a no-go. > Yes, ufs2-journaling is being worked on by Scott Long and a SoC developer, but I think the project is stalled, not 100% certain on that though. gjournal, at least the original implementation, does not stop you from having to fsck - it is there merely as a means to roll-back block changes, but ignores the filesystem. While handy and interesting, not useful for filesystem consistency. Now, I've heard that it is being re-implemented, and may provide different features. >>> I've ran, and is about to do so, a major newfeed machine, >>> >> which use alot >> >>> of disk i/o, on UFS2 without any trouble. >>> With softupdate in UFS2 the fsck in case of a crash is very time >>> limited. >>> >> I don't believe softupdates changes the recovery time any significant >> amount, but it does ensure meta-data consistency. With >> background fsck, >> your startup time can be reduced, which is very nice. >> > > Ah.. yes, but with background fsck you atleast get the system online > quicker then with single-user fsck which can take hours on huge > slices/partitions, altho the system might be alot slower then usual > atleast the services are running. > Newfeed(inn) got real grumpy when the background fsck were running on > its spool disks :> > Yea, for me, I want the service online, even if it is slow. For me, slow means work continues, and systems keep running - offline means $$. >>> As for XFS and ReiserFS support you do have the support in ports: >>> >>> Path: /usr/ports/sysutils/progsreiserfs >>> Info: Utilities and library to manipulate ReiserFS partitions >>> >>> Path: /usr/ports/sysutils/xfsprogs >>> Info: A set of utilities and library to manipulate an xfs >>> >> filesystem >> >> Note that those are read-only support. >> > > Ah.. figures! > (I did say I havent used them!) > > >> I have many FreeBSD servers here, that are *VERY HEAVILY* >> used, and the >> entire company depends on them. I have 100's of GB's to tens of TB's >> hosted on FreeBSD servers, and I'm very happy to say it performs >> incredibly well, and is very stable. Both 5.4(STABLE) and >> 6-STABLE are >> very solid for serving. >> > > Same same. Most of our hosting and colocation servers that run a *nix > type system are FreeBSD and they all do there job very well. > > >> One thing to be warned about - the larger the single filesystem, the >> more memory you will need for fsck's. Actually, it's more >> dependant on >> number of files, but the relationship is there. Full 2Tb filesystems >> (for me) require about 2.5GB of memory available for fsck use, YMMV. >> > > True! > Altho with 2Tb FS you probably want alot of MEM anyways, just to keep > the system happy and responsive. Altho over 4G on a 32bit system is a > no-no, alteast in SMP systems. Very true.. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43C7A542.6080303>