Roy Schestowitz wrote in <1502054.3cqEXbQysQ@xxxxxxxxxxxxxxx> on Mon May 15
2006 05:40:
>
> __/ [ Michael B. Trausch ] on Monday 15 May 2006 03:24 \__
>
>> Roy Schestowitz wrote in <3334203.1TK6lPLBb8@xxxxxxxxxxxxxxx> on Sat May
>> 13 2006 23:03:
>>>
[snip]
>>
>> Yes, RPM doesn't come out-of-the-box on FreeBSD, though you can install a
>> Linux compatibility layer and, in theory, use RPM on a FreeBSD box. I
>> don't know why you'd want to do that, though; I've never been a fan of
>> RPM, myself.
>>
>> That having been said, I think that FreeBSD is an *excellent* choice for
>> server systems, right up there with Linux. You can use the ports system
>> to install an application on your system from source, while being able to
>> configure what it interoperates with on the system, which is rather nice.
>> If you don't like the ports system, they have pre-compiled binaries that
>> you can use, as well, with their own package manager.
>
> Netscraft run many of their servers (if not all) on BSD. I once read about
> some theories surrounding uptime, the context being figures at Netcraft. I
> think a mailing list message indicated that some of their machines had run
> for about 4 years (non-stop). Others were no real exception. I suspect,
> however, that some distributions have a mechanism for automatic reboot. I
> may be wrong and I cannot recall what timescale we're talking about,
> either.
>
The BSD family is *quite* stable. They tend to have different developmental
focus then the Linux set of systems, which is alright -- each system does
happen to have niches that they perform better in. Linux, to me, is a
great general-purpose, all-around system. Of course, it runs the four
desktops in my apartment, and the one server, and that's fine with me. :)
I've never had uptime that ran up that far, however, because of power
outages and the like (and I've never been able to justify the spending on a
UPS-unit, even back in the dark ages without a journaling filesystem).
Then again, in practice, I haven't seen many machines that stay up
*horribly* long like that if they're truly multiuser machines, as they
reboot every so often to clean up /tmp, core files, and the like (hey, boot
up is a wonderful time to perform that type of regular maintenance, as well
as a good way to make sure that the system still boots -- if it doesn't
come up from a regularly scheduled reboot, you can replace the dead
hardware right away, instead of waiting for the next time you upgrade the
kernel and *have* to reboot :)). I have an account at freeshell.org --
which uses BSD -- and they reboot 7 of their 8 machines every Saturday
night -- save for the mailserver. They've caught a few system failures
early-on that way, which is of course a good thing.
>
>> The one thing that it has in its favor on a server is that the filesystem
>> that is used by default in newer FreeBSD installations is UFS2, which
>> supports filesystem snapshots at the FS level, and that's a wonderful
>> thing to have when you want to dump(1) or tar(1) a filesystem that's
>> running with
>> users on it. Create the snapshot and use your backup tool of choice on
>> the snapshot, which makes life a lot easier -- you don't have to worry
>> about
>> files changing while the backup system is running, that's for sure. :)
>> That means that you get a consistent point-in-time backup, which is quite
>> nice.
>
> Intersting that you mention backup in this context. I shifted my backup
> procedures from scp to rsync some days ago. I will now stick to a mixture
> of the two, recurring at different intervals. I also use tar (tape
> archive) to dump bi-weekly mirrors of my hard-drives to a large storage
> unit. But here comes to point which refers to yours: I _had_ to stick to
> tar archives (or equivalents) as the storage unit uses NTFS. It does not
> preserve case-sensitivity, which to me is crucial.
>
Yeah -- what we did in that one situation was we would run a level 0 dump
every Friday evening, burned to DVD, duplicate the DVD, take one of the
copies off-site, and then have intermediary Level 1 and Level 2 dumps made
over the network to an off-site location. Extremely nice way of doing
things, if you ask me, because it provides redundancy in how the filesystem
backups are done, in the event of drive failure (the machine only has a
single SATA drive in it -- it's only a *very* small office) or some other
catastrophic failure, such as the current acting SA accidentally doing
something to muck up the partitions.
>
>> It would be rather nice to see Linux have that functionality on the
>> filesystem level, though it doesn't appear to. It looks as if you have
>> to be using LVM on the system, with the filesystem in a logical volume,
>> and
>> with a VFS patch for LVM in the Linux kernel. My desktop systems don't
>> need the functionality, and neither do most of my (non-critical) servers.
>> However, I've had a couple of servers that I've set up (in offices, etc.)
>> where it is quite important to have the PIT backups without downtime, and
>> so I've used FreeBSD on those systems and come to rather like it.
>
> I will definitely keep this in mind if I ever take storage more seriously.
> Vis-a-vis storage problem, have you heard about Google recently? There are
> many speculations, as well as rants from Webmasters, me included.
>
No, can't say that I know exactly to what you're referring to on the Google
thing, so I don't know what type of storage problems they're having. I did
do a quick search though, and found some information from April wherein
they said that they were in the midst of a crisis. It's not hard to
believe, given the goals that they have of cataloging virtually everything.
Really, that's a hell of a lot of information. I don't know for sure what
their strategy for storage is, either, so I can't think about the problem
that they're having too much, since I don't know what the real root of it
is.
[snip].
>
> Thanks a million for the detailed information. Too valuable to <snip>...
>
No problem. FreeBSD is quite nice for certain things, though I don't use it
everywhere. Though, I snipped anyway because this post was getting rather
large. :)
- Mike
|
|
