HFS Plus (HFS+) is a fragile and a little outdated filesystem. If you google it, you'll find many reports of filesystem corruption.

Rebooting without unmounting the filesystem is the best way to corrupt it. This happens when the mac freezes for some reason (in my case it's the nvidia video card) or power failures.

Here are some tips, that IMHO should lower the chance of filesystem corruption:

1. When system freezes, try rebooting from ssh. When the graphics subsystem of my mac freeses, it's still accessible via SSH - try opening ssh connection from your network and reboot it. You could use Apple Remote Desktop (€62) for this task. You should enable ssh access first.

2. Do diskutil verifyVolume / periodically. Yes, even if HFS+ is a journaled filesystem, corruption is possible. You could use Apple Remote Desktop to run this on all classroom computers at once.

3. Use multiple volumes. Using multiple volumes should reduce chance for corruption. Splitting / from /Users/ should make restoration easier (either / or /Users will be corrupted). Note that this probably could complicate things with Bootcamp.

4. Mount partition(s) with options, which reduce writing. Mounting partitions with noatime option should reduce writing on it. By default every time a file is accessed, it's access timestamp is "touched".

5. Make sure there are no attempts to mount HFS+ partition from other os-es. Is it possible that someone is starting a linux distro from usb/dvd and mounting / in rw mode or playing with journal settings?

Hope my answer is helpful.

ps. corruption usually is gradual not sudden. There is a possibility that something specific is causing this, software or workflow. My mind is at Parallels 5, but it should corrupt the bootcamp volume, not the MacOS one. Searching their KB does not reveal anything useful.

Addendum:

To reply to the below commentary, it is fragile because it has no actual system to correct corruption within a file. A journal records transfers and attempts to recopy data in order to return the filesystem to a consistent state but if the file lost is vital (like actual filesystem structure data) then there is no recourse. In fact, because the Catalog File (which is lists all the logical data information) is stored as a file, if it corrupted in certain places your entire filesystem is rendered useless garbage data, or partially tended garbage in the event that it is corrupted and the a journal replay occurs which causes it to restructure the filesystem in a way that is not consistent with the data (e.g. file a and b are 1MB and 2MB respectively but the replay changes them to be 2MB and 1MB resulting in half of the contents of B being inside A).

It's outdated because aside from Journalling it's essentially the same filesystem from 1994 Copland OS and that is essentially HFS from 1984 with B-Trees and Blocks modified to suit larger filesystems. HFS is only marginally more secure than FAT.

HFS Plus (HFS+) is a fragile and a little outdated filesystem. If you google it, you'll find many reports of filesystem corruption.

Rebooting without unmounting the filesystem is the best way to corrupt it. This happens when the mac freezes for some reason (in my case it's the nvidia video card) or power failures.

Here are some tips, that IMHO should lower the chance of filesystem corruption:

1. When system freezes, try rebooting from ssh. When the graphics subsystem of my mac freeses, it's still accessible via SSH - try opening ssh connection from your network and reboot it. You could use Apple Remote Desktop (€62) for this task. You should enable ssh access first.

2. Do diskutil verifyVolume / periodically. Yes, even if HFS+ is a journaled filesystem, corruption is possible. You could use Apple Remote Desktop to run this on all classroom computers at once.

3. Use multiple volumes. Using multiple volumes should reduce chance for corruption. Splitting / from /Users/ should make restoration easier (either / or /Users will be corrupted). Note that this probably could complicate things with Bootcamp.

4. Mount partition(s) with options, which reduce writing. Mounting partitions with noatime option should reduce writing on it. By default every time a file is accessed, it's access timestamp is "touched".

5. Make sure there are no attempts to mount HFS+ partition from other os-es. Is it possible that someone is starting a linux distro from usb/dvd and mounting / in rw mode or playing with journal settings?

Hope my answer is helpful.

PS: corruption usually is gradual not sudden. There is a possibility that something specific is causing this, software or workflow. My mind is at Parallels 5, but it should corrupt the bootcamp volume, not the MacOS one. Searching their KB does not reveal anything useful.

PPS: it is fragile because it has no actual system to correct corruption within a file. A journal records transfers and attempts to recopy data in order to return the filesystem to a consistent state but if the file lost is vital (like actual filesystem structure data) then there is no recourse. In fact, because the Catalog File (which is lists all the logical data information) is stored as a file, if it corrupted in certain places your entire filesystem is rendered useless garbage data, or partially tended garbage in the event that it is corrupted and the a journal replay occurs which causes it to restructure the filesystem in a way that is not consistent with the data (e.g. file a and b are 1MB and 2MB respectively but the replay changes them to be 2MB and 1MB resulting in half of the contents of B being inside A).

HFS Plus (HFS+) is a fragile and a little outdated filesystem. If you google it, you'll find many reports of filesystem corruption.

Rebooting without unmounting the filesystem is the best way to corrupt it. This happens when the mac freezes for some reason (in my case it's the nvidia video card) or power failures.

Here are some tips, that IMHO should lower the chance of filesystem corruption:

1. When system freezes, try rebooting from ssh. When the graphics subsystem of my mac freeses, it's still accessible via SSH - try opening ssh connection from your network and reboot it. You could use Apple Remote Desktop (€62) for this task. You should enable ssh access first.

2. Do diskutil verifyVolume / periodically. Yes, even if HFS+ is a journaled filesystem, corruption is possible. You could use Apple Remote Desktop to run this on all classroom computers at once.

3. Use multiple volumes. Using multiple volumes should reduce chance for corruption. Splitting / from /Users/ should make restoration easier (either / or /Users will be corrupted). Note that this probably could complicate things with Bootcamp.

4. Mount partition(s) with options, which reduce writing. Mounting partitions with noatime option should reduce writing on it. By default every time a file is accessed, it's access timestamp is "touched".

5. Make sure there are no attempts to mount HFS+ partition from other os-es. Is it possible that someone is starting a linux distro from usb/dvd and mounting / in rw mode or playing with journal settings?

Hope my answer is helpful.

ps. corruption usually is gradual not sudden. There is a possibility that something specific is causing this, software or workflow. My mind is at Parallels 5, but it should corrupt the bootcamp volume, not the MacOS one. Searching their KB does not reveal anything useful.

HFS Plus (HFS+) is a fragile and a little outdated filesystem. If you google it, you'll find many reports of filesystem corruption.

Rebooting without unmounting the filesystem is the best way to corrupt it. This happens when the mac freezes for some reason (in my case it's the nvidia video card) or power failures.

Here are some tips, that IMHO should lower the chance of filesystem corruption:

1. When system freezes, try rebooting from ssh. When the graphics subsystem of my mac freeses, it's still accessible via SSH - try opening ssh connection from your network and reboot it. You could use Apple Remote Desktop (€62) for this task. You should enable ssh access first.

2. Do diskutil verifyVolume / periodically. Yes, even if HFS+ is a journaled filesystem, corruption is possible. You could use Apple Remote Desktop to run this on all classroom computers at once.

3. Use multiple volumes. Using multiple volumes should reduce chance for corruption. Splitting / from /Users/ should make restoration easier (either / or /Users will be corrupted). Note that this probably could complicate things with Bootcamp.

4. Mount partition(s) with options, which reduce writing. Mounting partitions with noatime option should reduce writing on it. By default every time a file is accessed, it's access timestamp is "touched".

5. Make sure there are no attempts to mount HFS+ partition from other os-es. Is it possible that someone is starting a linux distro from usb/dvd and mounting / in rw mode or playing with journal settings?

Hope my answer is helpful.

ps. corruption usually is gradual not sudden. There is a possibility that something specific is causing this, software or workflow. My mind is at Parallels 5, but it should corrupt the bootcamp volume, not the MacOS one. Searching their KB does not reveal anything useful.

Addendum:

To reply to the below commentary, it is fragile because it has no actual system to correct corruption within a file. A journal records transfers and attempts to recopy data in order to return the filesystem to a consistent state but if the file lost is vital (like actual filesystem structure data) then there is no recourse. In fact, because the Catalog File (which is lists all the logical data information) is stored as a file, if it corrupted in certain places your entire filesystem is rendered useless garbage data, or partially tended garbage in the event that it is corrupted and the a journal replay occurs which causes it to restructure the filesystem in a way that is not consistent with the data (e.g. file a and b are 1MB and 2MB respectively but the replay changes them to be 2MB and 1MB resulting in half of the contents of B being inside A).

It's outdated because aside from Journalling it's essentially the same filesystem from 1994 Copland OS and that is essentially HFS from 1984 with B-Trees and Blocks modified to suit larger filesystems. HFS is only marginally more secure than FAT.