Sorry about replying with the wrong link - I was originally hitting 'reply' but then my posts seems to be hidden so reverted to the other, I see the reasons to use reply now.
Anyway re storable I might as well try it tomorrow, quick to try and if it speeds things up it will be helpful. Since you mentioned log structured file systems I've been reading up and trying to get my head around how they would appear on disk - theres references to this in the OpenSSD source and it does seem likely (perhaps even inevitable) that this disk will use one. But my understanding of them is thin currently, although a bit better after reading on the topic. Certainly what I see so far seems to fit with a log structure (to me at least), its just missing a sequence number but I think its likely I just haven't found that yet.
What info on SSD log structure design is available seems to point to a more complex design than the 'classroom' one, to be expected I suppose, with data on wear levelling, write count etc also needing to be stored somewhere. But then also it seems to me that a SSD would likely not want to scan too much on start up for speed reasons, preferring to cache a single map file of around 60MB somewhere for startup. Then the LBA area that I am reading is there for backup in case the cached map is damaged, although the stale page data should also be there in that case. That map file would need to move around the disk a lot I imagine, otherwise the physical block its assigned to would wear quickly. I have binary grepped the disk for some segments of the map file I created but found no match however, but perhaps I need to conduct a more sophisticated search than a simple hex grep. It would certainly be convenient to find such a file.
The field in bank 32 is short - IIRC 128 bytes of 'active' data, IE data which varies across rows. The next couple of hundred bytes contain a pattern but its the same across all instances of bank 32 so it can't be significant. Today I spent a little time looking at the data in the field but not much, I'll hopefully do a little more tomorrow and can say a bit more. What I did see today though when I looked at it in binary is that in most rows there are just a few bits as 1, or pairs of 1s, with the vast majority being 0's. The numbers range from 0 to very high (IIRC 500M or more) so its not addresses. And theres far too little variation for it to store much data, apart from perhaps as a whole (the entire disks worth of bank 32 data). I'll post a bit of it, and if I can find somewhere to host it I'll put a couple of megs worth up for anyone to look at if they have the time.
Re the LBA 128 field, although I have not analysed it properly I remember that simple analysis showed a lot of repetition. That put me off the idea of it being a sequence number, my initial thought. But reading up on the log structure there simply must be a sequence number somewhere, and it makes no sense to not put it in the block being written (perhaps elsewhere too), so I think I need to hunt more for that. Perhaps repetition is permissible, if multiple blocks are written in a 'transaction', for instance.
I'm in the UK so its 1am now and I have to knock off but thanks for the assistance and ideas and I'll hopefully come back with some more info tomorrow.
Thanks, Pete
In reply to Re^3: Adding cols to 3d arrays - syntax
by peterrowse
in thread Adding cols to 3d arrays - syntax
by peterrowse
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |