6 ms·

Cool explanation but I wonder why other operating systems don't have the same restriction. On OSX, for example, it used to be here: /private/var/vm/sleepimage

by tbrock 11y ago

Cool explanation but I wonder why other operating systems don't have the same restriction. On OSX, for example, it used to be here: /private/var/vm/sleepimage I suppose they have a clever boot loader with advanced drivers?

wazari972 11y ago
I think bootloaders for Linux have more stages: the initial problem is the same, but then GRUB loads its configuration from [/boot]/grub2/grub.cfg. If it can load a config file, it can also load FS drivers or hibernation files, and prepare the actual kernel boot more subtlety.
- andreiw 11y ago
  Keep in mind this article was written in 2007 about the majority of NT installations at that time. Vista introduced a new unified boot architecture that replaced NTLDR with something that could work on BIOS and UEFI as well (and removed the monolithic EFI loader).
Someone 11y ago
I don't know whether they do, but a clever alternative is to have a stupid boot loader. You don't need to know how to traverse directories, you just need to know what blocks on disk to read. So, just write the number of the first block of the hibernation file to a known location (say in the first disk block) and you are all set. Well, all: the file may be fragmented. Just store information about where to find all the blocks in the first block of the hibernation file (alternative view of this is that you have a very simple alternative file system on the disk that stores only one file (or a few, if you also want the ability to find the kernel for a cold boot) Risk with such approaches is that they may not survive defragmentation of the drive. That's a minor risk for a hibernation file, I would say.
- wfunction 11y ago
  It's not minor. It's a freaking pain in the rear to have to fix this every time you defragment or move/resize a partition.
  - hmottestad 11y ago
    before the os goes into hibernation it can write the location of the hibernation image file to a special place for the bootloader to find. OSX also reserves space for the hibernation image, so it shouldn't get fragmented. And the defrag program probably doesn't increase the fragmentation for large files anyway.
  - Someone 11y ago
    If your defragmenter knows about the hibernation system, it will update the 'pointer' to the hibernation file. Also, you can only hibernate an OS that knows about hibernation. Such an OS would be foolish if it wouldn't write the current location of the hibernation file whenever it went into hibernation. So, this only is a problem if you hibernate your system, defragment its disk on another system using a defragmenter that doesn't know about hibernation files, and then try to wake up from hibernation. That might happen to people using an old version of a defragmenter, but I doubt it will happen often.
vetinari 11y ago
It's because the bootloader contains support for given filesystem. GRUB supports several filesystems, and so does UEFI (FAT read-write) and EFI on Macs (FAT read-write, HFS+ read only).
- mnw21cam 11y ago
  Back in the good old days, when LILO was the preferred boot loader for Linux, it did not have any idea how to read filesystems, and the block locations were simply recorded into the MBR. I remember when GRUB first came out, thinking it was somewhat heretical to have filesystem code in a boot loader.
  - vezzy-fnord 11y ago
    Slackware still uses LILO. Although most people will look at you like you're a fossil for using it these days, I've found it quite simple to configure and it has generally worked without a hitch.
    - digi_owl 11y ago
      Grub1 was not so bad to configure either, but Grub2 looks like a real stinker. The biggest gotcha with LILO is that thing about writing the config to the boot sector. But then i have not used it in some years...
      - semi-extrinsic 11y ago
        Personally I prefer syslinux, where the config resides in a easy-to-understand textfile, /boot/syslinux/syslinux.cfg, which can be on FAT or ext2/3/4 or btrfs. The only limitation is that all files that syslinux reads must be on the same partition. Grub2 OTOH is definitely an abomination. Whoever thought it a good idea to require compiling the bootloader config into a binary should be given a thorough slapping with a medium-sized trout. That thing is an overengineered solution looking for a problem.
        11y ago
lgg 11y ago
HFS+ stores the extent records for certain essential files (the bootloader, the catalog file, the extents overflow file, the journal, etc) in the file system header. So in order to find their physical locations you just need to read in the files system header and parse it.

by tbrock 11y ago

wazari972 11y ago

I think bootloaders for Linux have more stages: the initial problem is the same, but then GRUB loads its configuration from [/boot]/grub2/grub.cfg. If it can load a config file, it can also load FS drivers or hibernation files, and prepare the actual kernel boot more subtlety.

andreiw 11y ago
Keep in mind this article was written in 2007 about the majority of NT installations at that time. Vista introduced a new unified boot architecture that replaced NTLDR with something that could work on BIOS and UEFI as well (and removed the monolithic EFI loader).

Someone 11y ago

I don't know whether they do, but a clever alternative is to have a stupid boot loader. You don't need to know how to traverse directories, you just need to know what blocks on disk to read. So, just write the number of the first block of the hibernation file to a known location (say in the first disk block) and you are all set. Well, all: the file may be fragmented. Just store information about where to find all the blocks in the first block of the hibernation file (alternative view of this is that you have a very simple alternative file system on the disk that stores only one file (or a few, if you also want the ability to find the kernel for a cold boot) Risk with such approaches is that they may not survive defragmentation of the drive. That's a minor risk for a hibernation file, I would say.

wfunction 11y ago
It's not minor. It's a freaking pain in the rear to have to fix this every time you defragment or move/resize a partition.
- hmottestad 11y ago
  before the os goes into hibernation it can write the location of the hibernation image file to a special place for the bootloader to find. OSX also reserves space for the hibernation image, so it shouldn't get fragmented. And the defrag program probably doesn't increase the fragmentation for large files anyway.
- Someone 11y ago
  If your defragmenter knows about the hibernation system, it will update the 'pointer' to the hibernation file. Also, you can only hibernate an OS that knows about hibernation. Such an OS would be foolish if it wouldn't write the current location of the hibernation file whenever it went into hibernation. So, this only is a problem if you hibernate your system, defragment its disk on another system using a defragmenter that doesn't know about hibernation files, and then try to wake up from hibernation. That might happen to people using an old version of a defragmenter, but I doubt it will happen often.

vetinari 11y ago

It's because the bootloader contains support for given filesystem. GRUB supports several filesystems, and so does UEFI (FAT read-write) and EFI on Macs (FAT read-write, HFS+ read only).

mnw21cam 11y ago
Back in the good old days, when LILO was the preferred boot loader for Linux, it did not have any idea how to read filesystems, and the block locations were simply recorded into the MBR. I remember when GRUB first came out, thinking it was somewhat heretical to have filesystem code in a boot loader.
- vezzy-fnord 11y ago
  Slackware still uses LILO. Although most people will look at you like you're a fossil for using it these days, I've found it quite simple to configure and it has generally worked without a hitch.
  - digi_owl 11y ago
    Grub1 was not so bad to configure either, but Grub2 looks like a real stinker. The biggest gotcha with LILO is that thing about writing the config to the boot sector. But then i have not used it in some years...
    - semi-extrinsic 11y ago
      Personally I prefer syslinux, where the config resides in a easy-to-understand textfile, /boot/syslinux/syslinux.cfg, which can be on FAT or ext2/3/4 or btrfs. The only limitation is that all files that syslinux reads must be on the same partition. Grub2 OTOH is definitely an abomination. Whoever thought it a good idea to require compiling the bootloader config into a binary should be given a thorough slapping with a medium-sized trout. That thing is an overengineered solution looking for a problem.
      - 11y ago

lgg 11y ago

HFS+ stores the extent records for certain essential files (the bootloader, the catalog file, the extents overflow file, the journal, etc) in the file system header. So in order to find their physical locations you just need to read in the files system header and parse it.