Past EED rants


Live leaderboard

Poker leaderboard

Voice of EED

Friday, 12 July 2002

NTFS = SUX0R [Lurks]

Ever since I've been using PCs, I've always formatted my volumes with FAT, in recent years FAT32. Even when using proper OSes like NT, Win2K and XP. My limited early experience with NTFS was that it was insanely slow and I recalled a problem where I had a drive corruption and nothing would fix it. The insanely slow thing was a laptop in fact, formatted with NTFS and yet appeared to have the slowest HD I have used since 20MB on a card in my A2000. There may have been other reasons, I appreciate this isn't a proper scientific analysis of the performance but that's why I've chosen FAT32 ever since.

Now, the other day a HD crashed in my work machine. An almost new Maxtor 540DX drive in fact, how odd! That was a bit of a bugger but shit happens. Fresh install, new HD and so on and I think... hey so many folks have queried my choice of FAT32 (including the EED boys) that I'll choose NTFS. Bish bash bosh.

Yesterday, my machine crashed. I don't know why. It was running fine for a couple of days but up pops a BSOD with 'NTFS' somewhere in the meaningless garbage that MS helpfully provides. Odd, brand new Win2K install and all that but, and I need to make this point now, I didn't and still do not necessarily believe that this crash had anything to do with a weakness or shortcoming in NTFS necessarily.

However, when I tried to reboot, I got that hyper annoying problem of a BSOD on boot complaining about inaccessable boot device. When Win2K boots it loads all of its driver files in 16-bit mode including drivers for accessing the HDs and so on. Then it fires up all the 32-bit drivers and carries on booting etc. So you often see this problem if you move a Win2K volume to another mobo with a different IDE controller and so on. Win2K wont start looking at your hardware until the essential 32-bit drivers (like disk access drivers) are running and if you can't run the 32-bit drivers, because the essential hardware has changed or at least is incompatible, then you get this sort of nonsense. Annoying but understandable to a degree.

Not the sort of thing you'd expect from a simple crash and not changing ANY hardware though, especially on a brand new install on fresh hardware that's been running fine for two days. Even more annoyingly, you can't get to a command prompt on NT based OSes, safe mode or whatever without loading the essential 32-bit drivers. So even safe mode command prompt will BSOD. Of course being an NTFS volume, I can't boot a floppy to get a command prompt to look at my install either.

I'm dragging this out now so I'll cut to the chase. After investigation I had concluded that the implementation of NTFS has a serious flaw where it is not possible to mount and access an NTFS volume in 32-bit mode when there is some form of corruption on the volume. Now of course this corruption shouldn't be there anyway on a journaling file system, it ought to just roll back the changes. That's not happening, the crash in NTFS itself according to my original BSOD if you recall, has resulted in some actual corruption of the NTFS volume which it's (obviously lame) journaling capabilities cannot resolve.

The solution was to take the drive out of that machine, place it in another and boot that machine. Bingo scandisk pops up, does a quick once over and fixes some extremely minor stuff - I mean the sort of shit you see scandisk fix all the time on reboot after a crash when using FAT32. I pop the drive back in my machine, and it boots perfectly and everything is cool.

Oh my lord how lame can you get! I mean what good would NTFS be for a server, even, if it crashed and couldn't reboot so far as to load scandisk to fix minor issues with the FS and restart the remote access services?! The implementation of NTFS assumes that it cannot be corrupted and will refuse to mount if it is. That's not good at all.

So the moral of the story is that I feel vindicated on my choice of FAT32 for small/boot partions all this time. Naturally I expect to get a load of people going 'I've not have that problem' which automatically means it doesn't exist :)


  1. There's a few ways you can boot from a floppy and get ntfs. Linux usually, check out And it's true, booting fucked ntfs can be a pain. Most Servers are therefore configured with a small drive on fat for booting only, with a NTFS partition for the important stuff, on a raid array.

  2. Yeah we knew I could boot linux to get access to the NTFS but we wouldn't then be able to run the scandisk or to repair it any other way. The moral of the story is, don't format your boot partition with NTFS kids!