Is it safe to Defrag a Bootable Flash Drive ?

[Alan_B]

I am wondering if the "start point" of the operating system is defined by sector identity or by path and file name.

 

I have been reading documentation on the MBR and boot startup and so far I have only a head ache.

 

Alan

[Augeas]

Please elucidate, Alan.

[Alan_B]

I have several bootable flash drives.

Some use Linux

Some use WinPE

 

I know that the MBR is used for booting and eventually results in the launch of whatever mini operating system is present.

I do not see any common start point (such as Auto.inf) in the partition on these drives,

and I am wondering if the MBR which is filled with hexadecimal numbers uses an absolute sector address that designates the start point,

or if it uses a file name and path for the start point,

or if defraggler magically recognises which files must never be moved.

 

I want to know if the drive will still boot correctly after files have been moved.

[Guest Keatah]

Power on

Bios loads track 0, sector 0 (512 byte MBR)

MBR loads NTLDR or BOOTMGR (this can be located anywhere in the root directory and is sector independent)

I've pushed my NTLDR file all over the disk in the past.

 

http://www.tburke.net/info/ntldr/ntldr_hacking_guide.htm#the

http://en.wikipedia.org/wiki/Ntloader

http://en.wikipedia.org/wiki/Master_boot_record

http://en.wikipedia.org/wiki/Windows_NT_startup_process

[Augeas]

As far as I know, or believe....

 

The MBR sits at sector zero on the storage device. On bootup the CPU's registers are initialised with default values and the Extended Instruction Pointer (EIP), which holds the address of the instruction being executed by the cpu, is set. This initial instruction is a jump to the BIOS entry point. The BIOS code runs a power-on self test (POST) and then locates the Master Boot Record at sector 0 on the disk.

 

The BIOS loads the MBR into RAM and transfers execution to the MBR boot code, which in turn checks the partition table within the MBR for an active partition. The MBR code loads the Volume Boot Record (VBR) code from sector zero of the selected partition, and that in turn loads the operating system kernel, completing the startup procedure.

 

If the storage device is partitioned - which it has to be for Windows - then (I assume that) the MBR isn't touched during a defrag as it lies outside the partitions and a defragger defrags partitions. I have no experience of unpartitioned storage devices, except that the boot sector of a non-partitioned disk is a VBR, there being no MBR. On the other hand a partitioned device has a VBR, which can quite easily be seen as $Boot in NTFS at sector zero, and partitions have been defragged zillions of times and still boot up.

 

I my opinion it should be quite feasable to defrag a bootable flash device. A defragger after all defrags the MFT, or FAT, or whatever, and doesn't access disk sectors directly. At some point you have to give it a go.

[Alan_B]

Power on

Bios loads track 0, sector 0 (512 byte MBR)

MBR loads NTLDR or BOOTMGR (this can be located anywhere in the root directory and is sector independent)

I've pushed my NTLDR file all over the disk in the past.

 

http://www.tburke.ne...g_guide.htm#the

http://en.wikipedia.org/wiki/Ntloader

http://en.wikipedia....ter_boot_record

http://en.wikipedia....startup_process

Many thanks for you answer

 

I can indeed discover the file NTLDR in the root of my Macrium Recovery Boot Flash Drive which is based on WinPE,

and now understand how this is sector independent because it is located by path and file name.

 

I do have a problem with my OCZ-Linux Boot Flash Drive.

it has neither NTLDR or BOOTMGR.

This is a complete list of all the files that Defraggler can see on the Flash Drive.

 

---------------------------------------------------------------------------
OCZ-LINUX (I:), FAT32, Capacity: 7.5 GB, Used: 59.0 MB (1%), Free: 7.5 GB (99%)
---------------------------------------------------------------------------
Total size: 59.0 MB, Fragmented Files (0), Total Fragments (15)
---------------------------------------------------------------------------
Filename Fragments Size Path
---------------------------------------------------------------------------
boot.msg 1 221 I:\boot\syslinux\
boot.cat 1 2048 I:\boot\syslinux\
ldlinux.sys 1 37376 I:\
[Folder Entry] 1 0 I:\boot
Uni-USB-Installer-Copying.txt 1 49088 I:\
Uni-USB-Installer-Readme.txt 1 14339 I:\
license.txt 1 18092 I:\
f3 1 1059 I:\boot\syslinux\
f2 1 870 I:\boot\syslinux\
core.gz 1 59244610 I:\boot\
[Folder Entry] 1 0 I:\boot\syslinux
vmlinuz 1 2491968 I:\boot\
f4 1 929 I:\boot\syslinux\
isolinux.bin 1 14336 I:\boot\syslinux\
syslinux.cfg 1 366 I:\boot\syslinux\ 

Thank you for the link to tburke...

I especially like

Systems with only Linux:

 

The details of the Linux boot process is a mystery to me beyond the basic sequence.

I have decided to let it remain a mystery to me also - I am still exhausted after my last attempt at understanding Wikipedia articles.

 

I will however act on the information that the sector location of the files is not relevant, only the path and file name.

 

N.B.

The file "boot.msg" is a text file that contains the message

Press <Enter> to begin or F2, F3, or F4 to view boot options.

and gives a link to

http://www.tinycorelinux.net/

[Alan_B]

The BIOS loads the MBR into RAM and transfers execution to the MBR boot code, which in turn checks the partition table within the MBR for an active partition. The MBR code loads the Volume Boot Record (VBR) code from sector zero of the selected partition, and that in turn loads the operating system kernel, completing the startup procedure.

Thanks - I was unaware of "Volume Boot Record",

and that has given me more to Google for.

 

My concern however was not that defragging would stray outside the partition and move the essential MBR ( or VBR ),

but that the MBR / VBR / whatever would designate the "Operating System" entry point by a fixed sector number and not by a file name.

 

I did not want to make a mistake and break my Boot Recovery tools to such an extent that they did not mend a broken system,

and that even worse they did not scream to a halt and abort,

but that they might totally miss-fire and do more damage than before.

 

I am now prepared to cautiously try my luck and "give it a go".

[Augeas]

To clarify, on a partitioned storage device there is one MBR per physical device, and one VBR per partition on that device. When a device isn't partitioned there is no MBR, but one VBR at sector zero.

 

The MBR is at logical sector zero on the device and VBRs are always at logical sector zero of the partition.

 

The VBR contains the logical cluster number for the MFT, and the MFT holds a record for file ntldr, which is the loader for XP (Vista onwards uses winload.exe).

 

You can spend many happy hours with WinHex and a calculator. But beware of little-endian - if you have any spare brain cells prepare to shed them now.

 

(My knowledge, such as it is, is all XP and NTFS.)

[Alan_B]

To clarify, on a partitioned storage device there is one MBR per physical device, and one VBR per partition on that device. When a device isn't partitioned there is no MBR, but one VBR at sector zero.

 

The MBR is at logical sector zero on the device and VBRs are always at logical sector zero of the partition.

 

The VBR contains the logical cluster number for the MFT, and the MFT holds a record for file ntldr, which is the loader for XP (Vista onwards uses winload.exe).

CLUNK - Another piece drops into my puzzle, Thanks.

 

A few weeks ago I secure erased my SSD and after a restart through the BIOS I booted into my Macrium Rescue Boot Flash Drive to restore an earlier Disc image backup.

I Restarted and my BIOS totally forgot that my SSD had any sort of Boot Priority,

and so with zero drama and no hysteria ( so like a man ) it went to my next boot priority which was my HDD,

and Windows was booted through the MBR of my HDD to my active partition (without drive letter) "System Reserved",

AND YET this launched Windows resident on my SSD and I never saw the difference.

Had it been running on my HDD then C:\ would have been 25 GB, not the 55 GB of my SSD.

 

I only knew something was wrong because when I used Partition Wizard,

although both the SSD and the HDD had an "Active" status for "System Reserved"

it was only the HDD that showed "Active & Boot"

 

I have just inspected and there is no NTLDR in either "System Reserved" or C:\,

but there are 375 KB sized BOOTMGR files in all of "System Reserved" and also in C:\ and also C:\boot\Macrium.

 

Until today I was thinking that IF ONLY Windows had never defaulted to a separate "System Reserved" as part of the installation,

then there would have been no need for a "hyperspace jump" from one partition to another that resulted in the "wrong" physical drive,

and I was thinking that avoiding an intermediate partition to partition hop would avoid that sort of accident,

but now I see that the MBR of the Active partition uses an absolute address number to designate BOOTMGR,

and this in turn uses a full path with drive letter to launch the installed Operating System,

so the same "hyperspace jump" would have occurred even if the Operating System had been on the Active partition.

 

I am glad I found out before I tried a new installation of Windows without any "System Reserved".

 

You can spend many happy hours with WinHex and a calculator. But beware of little-endian - if you have any spare brain cells prepare to shed them now.

Little-Endian and Big-Endian is all BAD-Indian to me - it takes of my scalp

 

Partition Wizard tells me that my SSD is 55.90 GB with 117234408 Sectors of 512 bytes per sector.

There are 2048 sectors per MByte so 117234408 / 2048 = 57243.36328125 MB - close enough.

The "Toolbox" from OCZ reports their SSD as having

Word 60: (M) cf30h 06fch Total number of user addressable logical sectors (DWord)

CF3006CFh / 2 = 67980367h KB = 1738015591 KB = 1738015591 / 1024 MB = 1697280 MB = 1657 GigaBytes - what a promise - dissappointment ahead.

6FCCF30h / 2 = 37E6798h KB = 58615704 KB = 58615704 / 1024 MB = 57241 MB - near enough

 

I hate Linux and stupid-endian arithmetic

 

(My knowledge, such as it is, is all XP and NTFS.)

My first experience was of DOS 3.3? on a maximum spec Compaq Luggable P.C. with a 20 MByte HDD.

I did a little bit of software using Edlin and Debug.

 

I never defragged because of the danger of a power failure and a corruption of my system,

and the consequent neccessity of first backing up my HDD on a massive stack of 160 KiloByte capacity 5.25 inch Floppy Discs.

Not a happy way to spend a weekend

 

I still do not defrag.

I am not afraid of Power loss because I have an APC battery backup supply,

but I am still afraid of the crash-ability of Windows.

Decades of Blue Screens and "You failed to shut down properly" have permanently scarred me.

 

N.B.

After 10 months daily use of my SSD it has only reached 1% fragmentation, as reported by Defraggler version 11.

 

I was always much happier with my 8 bit 6800 Microprocessor based computer that never crashed,

and always shut down when I told it to and never refused and subsequently blamed me for not shutting it down properly.

[Augeas]

You'll love this. At offset 0x40 in the VBR is a single byte holding a value representing the record size in the MFT (mercifully as it's one byte, no-endian at all). If this value is positive then it represents the number of clusters per MFT record. If the value is negative however, as it most likely will be, then it is resolved by raising 2 to the power of the absolute value of this entity. The value is most likely to be 0xF6, which is -10, so the MFT record size is 2 to the power of 10, which is 1024.

 

A masterpiece of ingenuity or a ridiculous flourish of complexity?

 

PS. If you ever get round to looking at bitmaps (and if you do then you're a lost cause), the individual bytes are in little-endian. Thank heavens there's a machine to work all this out.

[Alan_B]

A masterpiece of ingenuity or a ridiculous flourish of complexity?

 

PS. If you ever get round to looking at bitmaps (and if you do then you're a lost cause), the individual bytes are in little-endian. Thank heavens there's a machine to work all this out.

I admire such diabolical cunning.

I pulled that sort of devious stunt many times with 8 bit arithmetic processors,

and received flak from colleagues over my source code's brief and cryptic documentation which was adequate for my needs but not their's

 

I take note of your information about bitmaps and will try to avoid them - brain cells are precious and I do not wish to wear them out.