[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Record uptime with GNU/kFreeBSD wheezy



Hi,

I think this is a good display of Debian GNU/kFreeBSD wheezy's stability
so far:

> $ uname -a
> GNU/kFreeBSD mail 9.0-2-amd64 #0 Wed Jun 19 21:22:42 BST 2013 x86_64 amd64 AMD Athlon(tm) 64 Processor 3700+ GNU/kFreeBSD
> $ uptime
>  02:04:14 up 416 days,  3:45,  1 user,  load average: 0.21, 0.70, 0.61

That is 416 days' continuous uptime on real hardware -- not a VM that
has been suspended/live-migrated at all.

It is an Internet-facing mailserver, on a ZFS root filesystem, with
software-mirrored SATA-attached disks that do a weekly scrub[0].  Some
files are backed up to there via rsync and retained in ZFS snapshots.
It's also using PF and jails.

ZFS was surprisingly stable despite only 2 GiB RAM and without any
sysctl tuning, although it has 6 GiB of swap.

Although there have been security vulnerabilities patched in kfreebsd-9
since then, the most serious seems to be a remote DoS;  the effect of
which would be to reboot it into a patched kernel, so I don't see a need
to reboot any sooner.

This beats my previous personal best uptime, which was a Debian squeeze
server that ran Linux 2.6.32 for 400 days uninterrupted, until
decommissioned.

[0]: SMART reports Reallocated_Sector_Ct still zero despite having grown
defects on both disks for some time now (Total_Pending_Sectors),
implying those must be in unallocated areas of the disk -- a neat thing
about ZFS is that unallocated blocks don't have to be scrubbed, whereas
Linux mdraid's equivalent data-check operation works on whole
partitions/disks, and would have caused those blocks to be remapped
already (depleting the spare blocks faster).

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org


Reply to: