by Alt » Sun Feb 20, 2011 5:18 am
Well, it's a bit hard to give advices without thoroughly browsing through the actual data on the disks. So, excuse me if I tell you something irrelevant or misleading.
thepuss wrote:
I'm not sure if this is a problem, but there appears to be a FAT16(?) partition at the start of the first disk, so I was wondering if the second disk needs some offset or other as a result, so that is starts at the same place as the NTFS partition on disk #1? Or will this be handled automatically?
It may be a remnant of a file system that had been on the disk before you made the RAID, or something else.
The offset of the second disk should be as you specified it when creating the RAID. Usually, the offsets for both disks are the same, but may be different.
thepuss wrote:
Anyway, I have mounted my two images: "Disk#1" and "Disk#2" and I know that they are in this order, so I believe I should only really need to look at "Disk #1" for all the general parameter info, since "Disk #2" is just going to be striped data... is this correct? (In any case I have not found an MBR on Disk#2...)
No, you should look on both disks, as the MFT, if large enough, may be stripped too, and be on both disks.
thepuss wrote:
Now, I get confused...
I can see the "File Record Number" of this first position... it is 00 00
If I skip forward 2 sectors, it changes to 01 00 (obviously the hex is inversed)
But, as I have neither 3 disks no parity in my case, I am lost at this point.
All the subsequent "2 sector skips forward" increment the File Record Number by 1, right up to FF 4E at sector 6405022 !
I'm sure this can't mean that my stripe size is 1K (2 sectors) can it ? That seems rather ludicrous...
Could someone point me in the right direction with this bit, and possibly tell me if I need to do anything else on Disk#2 or if it just has to be added to the Raid Set when it is defined.
Stop!!! Here you missed the point. You need to find a place in the MFT where the file record numbers, which until that place should be continuously changing by 1 (0, 1, 2, 3, 4, 5... - in inverse HEX, of course), are abruptly interrupted. Say, from 63 to 127, in inverse HEX once again. Then you should look at the second disk and find a file record number 64, to be sure that the MFT is not damaged. You should see that the length of such continuous block is also 64 file records. Then, the block size equals to 1 KB (the file record size) x the number of file records in the continuous block, 64KB for this case. Don't forget they start from 0 rather than 1!
I give these numbers for the most common case of 64KB stripe size. If it's different, the numbers'll be different.
As you have only two disks and no parity, and you know the disk order, your task is much easier. You don't have to determine which disk is which.
thepuss wrote:
At the moment I am going ahead with a full scan of the set, using the 64k stripe size, as this seems to be the NVRaid default ("Optimal"), and I can't think it would have been changed.
I agree with you.
Well, it's a bit hard to give advices without thoroughly browsing through the actual data on the disks. So, excuse me if I tell you something irrelevant or misleading.
[quote="thepuss"]
I'm not sure if this is a problem, but there appears to be a FAT16(?) partition at the start of the first disk, so I was wondering if the second disk needs some offset or other as a result, so that is starts at the same place as the NTFS partition on disk #1? Or will this be handled automatically?[/quote]
It may be a remnant of a file system that had been on the disk before you made the RAID, or something else.
The offset of the second disk should be as you specified it when creating the RAID. Usually, the offsets for both disks are the same, but may be different.
[quote="thepuss"]
Anyway, I have mounted my two images: "Disk#1" and "Disk#2" and I know that they are in this order, so I believe I should only really need to look at "Disk #1" for all the general parameter info, since "Disk #2" is just going to be striped data... is this correct? (In any case I have not found an MBR on Disk#2...)[/quote]
No, you should look on both disks, as the MFT, if large enough, may be stripped too, and be on both disks.
[quote="thepuss"]
Now, I get confused...
I can see the "File Record Number" of this first position... it is 00 00
If I skip forward 2 sectors, it changes to 01 00 (obviously the hex is inversed)
But, as I have neither 3 disks no parity in my case, I am lost at this point.
All the subsequent "2 sector skips forward" increment the File Record Number by 1, right up to FF 4E at sector 6405022 !
I'm sure this can't mean that my stripe size is 1K (2 sectors) can it ? That seems rather ludicrous...
Could someone point me in the right direction with this bit, and possibly tell me if I need to do anything else on Disk#2 or if it just has to be added to the Raid Set when it is defined.
[/quote]
Stop!!! Here you missed the point. You need to find a place in the MFT where the file record numbers, which until that place should be continuously changing by 1 (0, 1, 2, 3, 4, 5... - in inverse HEX, of course), are abruptly interrupted. Say, from 63 to 127, in inverse HEX once again. Then you should look at the second disk and find a file record number 64, to be sure that the MFT is not damaged. You should see that the length of such continuous block is also 64 file records. Then, the block size equals to 1 KB (the file record size) x the number of file records in the continuous block, 64KB for this case. Don't forget they start from 0 rather than 1!
I give these numbers for the most common case of 64KB stripe size. If it's different, the numbers'll be different.
As you have only two disks and no parity, and you know the disk order, your task is much easier. You don't have to determine which disk is which.
[quote="thepuss"]
At the moment I am going ahead with a full scan of the set, using the 64k stripe size, as this seems to be the NVRaid default ("Optimal"), and I can't think it would have been changed.
[/quote]
I agree with you.