Hmm not sure if I did the right thing replying here, had to click to see your post and the page I am seeing does not offer me a reply link only a comment one. If someone is going to clean up this thread thats great but let me know if my settings are wrong or something with your reply being hidden on the original page.
Spoiler alert: I successfully mounted the drive today, although its quite 'damaged', but mount accepted it.
Anyway re your post I haven't had time yet to explore the suggestions re flags, working this morning (while looking after one of my little ones so a bit disjointedly) on examining the field we are talking about in a more basic fashion. The repetition is considerable, but there is another 4 bytes after the LBA 128 field we discussed and I wondered if it might be part of the sequence number but it seems not. I'll have to check what you were saying about the bit fields marking only a single LBA valid - its an interesting thought.
Re the write repeatedly point I think I remember seeing in the datasheet that this is forbidden - I'll have to check to be sure but I remember thinking its very restrictive. If it was permitted it could allow a validity field with 0 being invalid which would be very good but I don't think so, will check later though.
I don't quite understand your point re the write count being reconstructed. Sounds interesting though and I will read this throughout the afternoon trying to understand it but might need to come back to you on it later.
As for the filesystem it was quite full IIRC, about 90% probably (good because there are fewer unused and hence stale pages). I don't think TRIM was used on this drive, it was running OSX (on PC hardware - a hackintosh, stupid experiment I made).
Now as for the mounting I mentioned earlier. Sleeping on the log structure details and a bit more reading made me wonder about something I saw in the drive some time ago. I made a bitmap image of sector average values to visualise the areas that might contain addresses (since they are 24 bit values occupying 32 bit space). I saw an interesting horizontal darker band about 10% of the drives capacity in size, occupying the space between about 80% and 90% of the drive space. IE towards the bottom. Looking in it did not show anything very significant and I put it aside for now. But the simple log structure file system I think can simply treat the whole drive as a log - at least that was my interpretation - and just keep writing to the head of the log, which would of course move along and wrap around to the bottom of the drive as it was written. I wondered if that dark band in any way marked this since I don't see why its there, the OS would not be aware of physical locations so could not be responsible. Anyway I decided to try writing out the map file starting from offset around 85% and wrapping via offset 0% back to 85%. Loading that map file into the kernel module allowed me to mount the image once I had provided the offset of the partitions starting block (found with HFS rescue).
Now although this creates almost as many questions as it answers, its an interesting turn. Why is the area darker for instance. I originally thought it should be light (IE all FF) but of course if it was not erased yet because the drive did not know it was unused it should not be. Perhaps OSX writes 0x00 to the whole drive when it formats, although this install was several months old so I imagine I had turned over the whole 256 gig by this time.
If its possible to upload images here I can upload the bitmap file. The dark band has fuzzy edges and is ill defined but certainly there.
Many of the folders in the root directory are now accessible, although how many files are readable I haven't checked yet. Some folders yield a ' Input/output error', and as you drill down through working folders you hit further such inaccessible ones. Still this is far further than I have got before so its significant. It might I guess be by chance that one or two significant blocks that hold top level directory information have been correctly selected now rather than a large proportion of blocks I don't know (understanding of FS structure too hazy).
I think next I should investigate your idea about the bitfields and duplicate LBA correlation now but if anything I have mentioned gives you any further ideas they would be much appreciated.
Thanks, Pete
In reply to Re^5: Adding cols to 3d arrays - syntax
by peterrowse
in thread Adding cols to 3d arrays - syntax
by peterrowse
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |