SG Enterprise encryption - Bad Sectors survey

Hi there,

seems like it might help to clear some things up in this thread.

MawfTech, you wrote:

Using that method, I now have no way of knowing impending surface failure on a drive without running a long diagnotic test.. By writing the kerneal area as bad sectors, you're now removing the ability for us guys to spot impending failures early…

Maybe there’’’’s a misunderstanding here. Opposed to your statement, we do not write anything as bad sectors, we only mark the protected areas as bad clusters in the file allocation table. So you got two different things here.

If you really want to check the physical health of the disks, there is no other way than to check for bad sectors (and if your drives feature S.M.A.R.T. technology, this will really ease your troubles, of course). Bad clusters are not a direct indicator for the physical health of a disk. This is also well documented for tools like chkdsk, and in the documentation for ScanDisk (http://support.microsoft.com/kb/q127055/) Microsoft even points you to encryption, among others, as an example of where you run into trouble when mixing up the two.

The remark of yours regarding SGE 4.x never used to do this may also be an indicator that the SGE bad clusters simply slipped by your health tests, which only adds to the point that you should try to directly test for the defects you’’’’re after.

petr_stipek, you wrote:

1. Create a file on the partition to be encrypted; make sure the file is contiguous (NTFS should do this for you; if not, defragment and repeat).
2. Set the file as immovable (possible on NTFS, and starting with Windows 7, also on FAT, AFAIK - see http://www.osronline.com/showthread.cfm?link=183894).
3. Write through to that file, and make a note you don't want to encrypt this one (should be easy, it is your driver working there).
4. Note the location of that file in sectors - regardless of the partition being encrypted or not, it is now sitting firmly on the hard disk.

The real challenge in software development, of course, is to find the simplest solution that reliably works.
1) is exactly what we are doing anyways.
2) to 4) may work, but it’’’’s brittle and complicated for a number of reasons, some obvious ones being that:
- our driver works on sector-level and, during normal operation, is actually not aware of any files at all, and
- what you describe is actually what bad cluster entries are designed for in the first place: keep your hands off these areas!

Why should we try to re-invent the wheel with a home-grown mechanism that the operating system is not even aware of? Doings so sounds like asking for trouble.

Some more food-for-thought, in addition to what I already mentioned:
- System-protecting files (as MawfTech suggested) works only on a running system, but not when you access the disk externally.
- Extra partitions may not only be cumbersome to create, especially if you need to downsize existing ones. They also may be deleted easily.

Hope that helps,

Hi there,

seems like it might help to clear some things up in this thread.

MawfTech, you wrote:

Using that method, I now have no way of knowing impending surface failure on a drive without running a long diagnotic test.. By writing the kerneal area as bad sectors, you're now removing the ability for us guys to spot impending failures early…

Maybe there’’’’s a misunderstanding here. Opposed to your statement, we do not write anything as bad sectors, we only mark the protected areas as bad clusters in the file allocation table. So you got two different things here.

If you really want to check the physical health of the disks, there is no other way than to check for bad sectors (and if your drives feature S.M.A.R.T. technology, this will really ease your troubles, of course). Bad clusters are not a direct indicator for the physical health of a disk. This is also well documented for tools like chkdsk, and in the documentation for ScanDisk (http://support.microsoft.com/kb/q127055/) Microsoft even points you to encryption, among others, as an example of where you run into trouble when mixing up the two.

The remark of yours regarding SGE 4.x never used to do this may also be an indicator that the SGE bad clusters simply slipped by your health tests, which only adds to the point that you should try to directly test for the defects you’’’’re after.

petr_stipek, you wrote:

1. Create a file on the partition to be encrypted; make sure the file is contiguous (NTFS should do this for you; if not, defragment and repeat).
2. Set the file as immovable (possible on NTFS, and starting with Windows 7, also on FAT, AFAIK - see http://www.osronline.com/showthread.cfm?link=183894).
3. Write through to that file, and make a note you don't want to encrypt this one (should be easy, it is your driver working there).
4. Note the location of that file in sectors - regardless of the partition being encrypted or not, it is now sitting firmly on the hard disk.

The real challenge in software development, of course, is to find the simplest solution that reliably works.
1) is exactly what we are doing anyways.
2) to 4) may work, but it’’’’s brittle and complicated for a number of reasons, some obvious ones being that:
- our driver works on sector-level and, during normal operation, is actually not aware of any files at all, and
- what you describe is actually what bad cluster entries are designed for in the first place: keep your hands off these areas!

Why should we try to re-invent the wheel with a home-grown mechanism that the operating system is not even aware of? Doings so sounds like asking for trouble.

Some more food-for-thought, in addition to what I already mentioned:
- System-protecting files (as MawfTech suggested) works only on a running system, but not when you access the disk externally.
- Extra partitions may not only be cumbersome to create, especially if you need to downsize existing ones. They also may be deleted easily.

Hope that helps,