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 [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
