Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rebooting is for Windows

zdnet.co.uk

Post reply on HN
Print view View original

21–30 of 44 posts

Re: Rebooting is for Windows

#21

Post by sprout »

runjake wrote: post #20
sprout wrote: post #19

Earlier quoted context omitted.

The biggest thing about Windows (and what I think makes it an unavoidably desktop-class environment) is that there's no kernel-level support for alternate filesystems. The various Unix-likes have a variety of filesystems with a lot of innovation going on. Windows basically just has NTFS, which while ok for the desktop is only going to serve well for some types of servers.

Yes, hopefully somebody will work on this some day. http://www.microsoft.com/whdc/devtools/ifskit/default.mspx http://www.microsoft.com/whdc/devtools/IFSKit/ifskit_about.m... http://www.fs-driver.org/ http://www.microsoft.com/whdc/DevTools/WDK/WDKpkg.mspx http://www.acc.umu.se/~bosse/ http://www.osr.com/seminars.html

Sorry, is that sarcasm? I honestly can't tell. Yes, people have implemented filesystems other than NTFS for Windows. NTFS is however the only one I personally would trust on a production server, especially for the system partition.

Linux, by contrast, has a variety of filesystems that are as stable if not more so than NTFS, and ready for production use on your root partition.

Linux probably has some catching up to do with respect to Solaris and the BSDs, but it has a good cut above desktop class filesystem support.

Re: Rebooting is for Windows

#22

Post by vog »

wizard_2 wrote: post #13
rbanffy wrote: post #11

Earlier quoted context omitted.

Can you move, rename or replace an open file with current Windows? That's possibly one of the reasons why it's so hard to apply patches without rebooting a Windows box. And an endless annoyance when using a Windows desktop.

Can you remove a logfile on linux/unix while something is using it? Of course you can but the open file will stay around in limbo. It wont free up space, the program that holds it open will write to the deleted file, etc. Most linux programs will let you send it a nohup and it will close and reopen the logfile, that's something I haven't a clue about on windows. I still pipe logs to a separate process that checks if…

> Of course you can but the open file will stay around in limbo. It wont free up space, the program that holds it open will write to the deleted file, etc.

This is actually a feature, because it makes secure temp files possible.

> I still pipe logs to a separate process that ...

Note that logging is usually done in a separate process anyway, using the Syslog facility.

Re: Rebooting is for Windows

#23

Post by runjake »

sprout wrote: post #21
runjake wrote: post #20

Earlier quoted context omitted.

Yes, hopefully somebody will work on this some day. http://www.microsoft.com/whdc/devtools/ifskit/default.mspx http://www.microsoft.com/whdc/devtools/IFSKit/ifskit_about.m... http://www.fs-driver.org/ http://www.microsoft.com/whdc/DevTools/WDK/WDKpkg.mspx http://www.acc.umu.se/~bosse/ http://www.osr.com/seminars.html

Sorry, is that sarcasm? I honestly can't tell. Yes, people have implemented filesystems other than NTFS for Windows. NTFS is however the only one I personally would trust on a production server, especially for the system partition. Linux, by contrast, has a variety of filesystems that are as stable if not more so than NTFS, and ready for production use on your root partition. Linux probably has some catching up to do…

I was referring to your original point that Windows didn't not have kernel-level support for alternate filesystems.

Obviously I don't know your use scenarios, but I can think of 2 Linux filesystems that I'd trust to varying extents and they both begin with "ext".

That said, I use the right tool for the right job. Much of the time it's Linux, and sometimes it's Windows 2008. Thank FSM the VMS boxes are gone.Platform agnosticism is a valuable trait to have.

Professionally, I haven't had a real use for anything other than NTFS on a wide variety of Windows servers, all the way up to double-digit TBs of data. What situations have you found NTFS inadequate for your needs?

My desktop has no direct need to handle millions of database transactions and terabytes of data, but it's nice that it can with NTFS.

Re: Rebooting is for Windows

#24

Post by vog »

rbanffy wrote: post #8
lurkinggrue wrote: post #6

Earlier quoted context omitted.

I have run into problems where the machine would not survive reboot after updates but did not find this out after months.

It's OK to reboot from time to time. What is not OK is to have a reboot imposed on you when you would rather continue running. It's not a huge disruption to reboot a cluster node, as long as the rest of the cluster takes the load. Rebooting makes sure the filesystem is properly scrubbed, temporary files are removed and any stale data in memory gets removed. Uptime competitions are pointless. But forced downtime (Wind…

> Uptime competitions are pointless.

While uptime competitions don't indicate availability very well, they do show how much time happened since the last kernel crash or the last kernel security hole that required a kernel upgrade and thus a reboot.

(Unless, of course, someone is trading security for uptime, which is luckily the exception rather the norm, at least among responsible admins.)

It appears that neither Windows nor Linux work particularly well here, but the BSD systems are quite impressive in that regard, especially OpenBSD.

Re: Rebooting is for Windows

#25

Post by jsz0 »

I don't keep up on enterprise Linux stuff much but after reading this it concerns me that Linux seems to have better in-place upgrade support than most of Cisco's big iron stuff I've worked with. The 10000 series routers I presently work with only recently got support for in-place upgrades and it has a list of caveats a mile long. From a network architecture standpoint you can't always (affordably) design around downtime but at least your servers can stay up while your network is done now.

Re: Rebooting is for Windows

#26

Post by sliverstorm »

vog wrote: post #24
rbanffy wrote: post #8

Earlier quoted context omitted.

It's OK to reboot from time to time. What is not OK is to have a reboot imposed on you when you would rather continue running. It's not a huge disruption to reboot a cluster node, as long as the rest of the cluster takes the load. Rebooting makes sure the filesystem is properly scrubbed, temporary files are removed and any stale data in memory gets removed. Uptime competitions are pointless. But forced downtime (Wind…

> Uptime competitions are pointless. While uptime competitions don't indicate availability very well, they do show how much time happened since the last kernel crash or the last kernel security hole that required a kernel upgrade and thus a reboot. (Unless, of course, someone is trading security for uptime, which is luckily the exception rather the norm, at least among responsible admins.) It appears that neither Win…

> the BSD systems are quite impressive in that regard, especially OpenBSD

From my experience with OpenBSD, this appears to be quite simply because things have been pruned so well, there's nothing to fail. What is there is well-designed, and IIRC my general purpose install was ~200MB.

The insanely lightweight and simple nature of OpenBSD is one of my favorite things about it, and probably one of the biggest contributing factors to its strengths.

Re: Rebooting is for Windows

#27

Post by Twirrim »

runjake wrote: post #23
sprout wrote: post #21

Earlier quoted context omitted.

Sorry, is that sarcasm? I honestly can't tell. Yes, people have implemented filesystems other than NTFS for Windows. NTFS is however the only one I personally would trust on a production server, especially for the system partition. Linux, by contrast, has a variety of filesystems that are as stable if not more so than NTFS, and ready for production use on your root partition. Linux probably has some catching up to do…

I was referring to your original point that Windows didn't not have kernel-level support for alternate filesystems. Obviously I don't know your use scenarios, but I can think of 2 Linux filesystems that I'd trust to varying extents and they both begin with "ext". That said, I use the right tool for the right job. Much of the time it's Linux, and sometimes it's Windows 2008. Thank FSM the VMS boxes are gone.Platform a…

Why the obsession with using one or the other? Why not see that both have their appropriate uses, strengths and weaknesses?

My focus as a Sysadmin is Linux, purely by nature of the type of work I'm in, so I tend to keep up only with the benchmarks relevant to me.

If you're only seeing ext2 & 3 as mature and stable you've missed great file systems like XFS.

ext2 & 3 are great all-rounders, but XFS will knock them into a top hat when it comes to larger files, with lower CPU usage and disk ops. It'll also beat ext2 and ext3 if you're creating and deleting lots of small files (like on an e-mail server) as the delete will take place in the background without impacting the front end systems. It's nice and mature too (16 years old). ext2 & 3 have slightly better error recovery though. XFS is journalled so very little should go wrong that would impact it.

JFS has strengths when large files are moved around on it, extremely low sector overhead (less than 1%) and very low CPU usage, amongst the lowest of any of the main Linux ones.

NTFS has no knowledge of checksumming, something ZFS, ext4 and btrfs handle (the latter two I wouldn't trust yet in production environments), but it does have integrated snapshots, something you generally have to use LVM for under Linux, and native encryption, and from Vista/2003 onwards supports shrinking and expansion directly on the fly (again LVM is necessary to do this under linux, and is best done with filesystem offline).

You chose your operating system and file system to suit the task (for example I'd use OpenBSD on a gateway machine instead of Linux as it's more suited to the role).

It's such a simple concept, like how you wouldn't use a hammer to crack an egg. You could, but you might find the edge of a knife or a spoon a lot easier and neater.

Re: Rebooting is for Windows

#28

Post by cparedes »

wizard_2 wrote: post #13
rbanffy wrote: post #11

Earlier quoted context omitted.

Can you move, rename or replace an open file with current Windows? That's possibly one of the reasons why it's so hard to apply patches without rebooting a Windows box. And an endless annoyance when using a Windows desktop.

Can you remove a logfile on linux/unix while something is using it? Of course you can but the open file will stay around in limbo. It wont free up space, the program that holds it open will write to the deleted file, etc. Most linux programs will let you send it a nohup and it will close and reopen the logfile, that's something I haven't a clue about on windows. I still pipe logs to a separate process that checks if…

If your intention is to totally remove the space that's occupied by the log file, you'll probably want to pipe /dev/null into the file:

cat /dev/null > /path/to/logfile

Re: Rebooting is for Windows

#29

Post by blueben »

sliverstorm wrote: post #18
kgo wrote: post #4

Eventually your hardware will fail. If you can't even safely reboot your machines under controlled circumstances, you've already lost the uptime battle.

Eventually parachutes need to be used. Now, they should work and save you, but why risk it if you don't have to?

Because if you don't exercise that functionality, you will never have confidence that it will work when you need it to.

Re: Rebooting is for Windows

#30

Post by whacker »

cparedes wrote: post #28
wizard_2 wrote: post #13

Earlier quoted context omitted.

Can you remove a logfile on linux/unix while something is using it? Of course you can but the open file will stay around in limbo. It wont free up space, the program that holds it open will write to the deleted file, etc. Most linux programs will let you send it a nohup and it will close and reopen the logfile, that's something I haven't a clue about on windows. I still pipe logs to a separate process that checks if…

If your intention is to totally remove the space that's occupied by the log file, you'll probably want to pipe /dev/null into the file: cat /dev/null > /path/to/logfile

That does not do what you think it does.

Your command will make /path/to/logfile fill up all available space on the disk. To truncate that file, which is probably what you wanted to do, you should

`echo > /path/to/logfile`

Post reply on HN