On Monday 10 March 2008 07:12:07 pm Mike Miller wrote:
> Mike Miller wrote:
> > Sure, but there is probably a reason why you think it is the best.
> > There must be some feature that you don't find in other Linux distros.
> > No?
>
> Shawn Fertch <sfertch at gmail.com> replied:
>
> Last time I used Slack (v11.0), it was still the smallest footprint out of
> all the major distros.  Yes there are others that are smaller, but they
> are typically minimalist to begin with such as DamnSmallLinux, etc.
>
> Personally, I like Slackware for the fact that out of all of the distros
> I've used, it's the closest to UNIX when compared to others.  Some people
> complain about it, but I prefer it because of working on the big UNIXes
> all day long and it's generally the most familiar to me.  It might not
> conform to the conglomerate of RHEL, Ubuntu, or others.  But, then again,
> standardization and Linux hasn't gone very well together, and most likely
> won't ever do so until it grows up and becomes a bit more of an enterprise
> friendly solution.
>
> -Shawn
>
>
>
> Good answer, Shawn.  Thanks.
>
> Mike
>

In a lot of ways what OS I'd be using depends heavily on my choice of 
filesystem.  My choice of filesystem depends on how big I'm going to go.

0 - ~2.5TB  UFS2 + SoftUpdates
2.5 TB - ~10TB XFS
10TB +  ZFS

In the first range I'd go with a FreeBSD or FreeNAS solution.  FreeBSD is all 
about stability and server applications.  UFS2 and softupdates were written 
by someone with a doctorate in CompSci, who specialized in filesystems and 
it's been around a long time with a proven record in regards to stability.  
The downside to this solution is that it still does a background fsck after a 
bad shutdown, which tanks I/O performance while it's running, and requires 
about a gig of RAM per TB of filesystem to complete.  People are running UFS2 
+SU up tp the 6-8TB range in production but I don't really recommend that in 
a situation where you might have to fsck (home solution with potentially 
unreliable power)

Second range I'd go with Debian linux.  XFS is hands-down the most tested and 
stable of the journelling filesystems out there, it was professionally 
written and ported to linux. (Thanks SGI)  It suffers from a need to fsck in 
the case of journal replay failure, and has the same 1 Gig of RAM per TB 
problem that UFS2 has, but in practice it takes hardware failure to provoke 
an fsck.  One caveat about XFS is that it caches writes extensively...you 
really don't want to lose power during heavy extended write load.  Debian is 
a great choice for intranet servers where security isn't a huge issue because 
the releases are based on stable well-tested versions of things.  Debian 
knows release engineering as well as any linux distro out there.  

Third range I'd go with ZFS on Solaris.  FreeBSD 7.x has ZFS but it's really 
not ready for prime time yet.  In this case you pay the RAM penalty up front 
but never have to worry about fscking at all.  If you look at the big Sun 
storage boxes (Like the X4500 and friends) you'll see they are over 1 Gig of 
RAM per TB just for "normal" operation. 

Other thoughts:  Linux has a fairly crappy NFS implimentation, unless all you 
are talking to is other linux boxes, in which case it works quite well.  
Linux also has kick-ass software RAID, and the ability to grow RAID arrays + 
xfs_grow is really really nice.  I've used a lot of software RAID 
implimentations, and linux's is as good as or better than anything available 
at any price. (Thanks IBM)  It's worth noting if you're willing to go all 
bleeding edge, FreeBSD 7.0 has geom virstor, which would provide a growable 
filesystem capability.

Ok, I'm out of time and energy on this topic, hope it helps.

-- 
Thanks,

Josh Paetzel

PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20080311/e2b0a27f/attachment.pgp