You did WHAT with the dead SSD? And the data?
Вставка
- Опубліковано 30 бер 2022
- Wendell got his hands on a corrupted Fusion io NAND flash drive, and let's just say, it consumed his life for a little bit.
**********************************
Thanks for watching our videos! If you want more, check us out online at the following places:
+ Website: level1techs.com/
+ Forums: forum.level1techs.com/
+ Store: store.level1techs.com/
+ Patreon: / level1
+ KoFi: ko-fi.com/level1techs
+ L1 Twitter: / level1techs
+ L1 Facebook: / level1techs
+ L1/PGP Streaming: / teampgp
+ Wendell Twitter: / tekwendell
+ Ryan Twitter: / pgpryan
+ Krista Twitter: / kreestuh
+ Business Inquiries/Brand Integrations: Queries@level1techs.com
IMPORTANT Any email lacking “level1techs.com” should be ignored and immediately reported to Queries@level1techs.com.
-------------------------------------------------------------------------------------------------------------
Music:
Intro and Outro: "Earth Bound" by Slynk
Other Music:
"Follow Her" and "Lively" by Zeeky Beats
[Cocktails and Lobsters] by Alexander Nakarada (www.serpentsoundstudios.com)
Licensed under Creative Commons BY Attribution 4.0 License
creativecommons.org/licenses/...
This is Wendell going full Wendell and I love it. This is why Level1Techs is top tier tech UA-cam: genuine expertise and ability, not just knowledge of properties of the product stack
This recovery adventure BADLY calls for a written piece on the side of it. a lot of background info was clearly cut from this, and an article could provide that, because the subject really deserves it...
26:03
Shocking, Microsoft tried to create a resilient file system that mimicked ZFS and did a piss poor job? Who'd have thought that would happen...
Wild that you got that mostly recovered from that insanity
Nice Wendell. When I got my first NVMe drive I found the namespace and raw access interface and had some fun ideas about what I could do with that, ie slicing it up with namespaces and using a raw flash filesystem on the raw sectors of one of the namespaces, like JFFS2 or logfs. The neat thing about that would be that the filesystem would be completely invisible to all but the most technical of users. BTW I don't think the ECC data is what you're looking for, or will ever find. That's at a lower layer than what you're accessing. You're looking for the FTL (Flash Translation Layer) data which provides the LBA block mapping and manages the SLC cache blocks and the over-provisioned blocks to give performance and absorb media errors similar to how HDDs have spare blocks to mitigate media errors, except SSDs have a lot more. Ok and having watched a little further... you didn't need to load it all into a database. You only needed to write the metadata to the database - that is, the LBA and the byte offset into the full device image. Then you could use the database to linearise the LBAs and stream them from the device image to a nice linear image, which you could then access via loop mount. And instead of a database you could have use a MMap'd file with the space for an array of the LBA locations... that would have been orders of magnitude faster than a DB.
Wendell casual ‘janitor’ casually do static analysis and comparative analysis and somewhat successfully reorder a shit ton. Of data , ok the approach is kinda brute forcy but omg great work… that wendell is too humble
This ties into my biggest concern for our future. There are one of a kind movies,pictures, and music from 100 plus years ago that we can see and hear today because they were recorded on a analog medium. In the old days grandma had one photo made in her entire life and we can see it but today grandma may have a 100k of pictures but we can't see them because a HDD died.
Wish I had more info to provide on this, but even in my 7 years of doing iodrive installs and support, plus all the iodrives in my home lab, never ran into an issue. I did have an i7-920 as my first home esx 5 server with an iodrive though.
Maybe the sequence just always adds one, ignoring overflow, assuming the GC would catch it before it loops again. So instead of grabbing the highest one, you'd need to grab the highest sequence value, that doesn't have one IMMEDIATELY after it (or in the first sequence, in the case of sequence.MAX_VALUE). IE if 8 was the max, and you had 1, 2, 7, 8, you wouldn't use Sequence 8, you'd use sequence 2. Just a thought! Very interesting content!
The "Jeff" from CraftComputing did a video about these drives some time ago, he got a bunch of those drives of various gens and even some software, maybe he knows something
Python can handle concurrency just fine if you use the Multiprocessing library (included in the Python standard library). Unlike the Threading library, it launches multiple python processes in order to make sure you're not time-slicing a single CPU core. These processes are not bound by the GIL, so in order to pass data around between the "threads", you need to use the data structures provided by the Multiprocessing library. I've found that producer/consumer thread models work quite well with this library.
At 520 bytes per sector (including 8 bytes of OOB data), I wonder if the FPGA handles ECC using a part of the OOB data that is hidden from you. Looking at a Micron 512Gb (64GB) datasheet from Datasheet Archive, it looks like the actual OOB data (744 bytes per 8k page) would be 46 bytes per sector, not 8 bytes per sector.
I've been doing computer janitor stuff for a while, so I know what an FPGA is. I still hear "field programmable gatorade" every time, though.
I am too dumb o understand anything in this video but man watching Wendell work is a treat!!! Computer janitor of the highest order!!!
I love that this came out on world backup day. Fantastic work. Makes me want to dig up my old 80 and 160gig FusionIO drives and see if I can get them running.
I just got about the gist of the whole saga ... but i love how Wendel explains everything even if i don't understand most of it. That's F.A.S.D for yah !
really like to see more support for fusion io drives. I have been using many of the sx300/350 card. Those things are tanks compare to NVMe drive. Their write life is in PB range, long pass their EOL/EOS date.
Thanks for the snip editor Autumn! Will be waiting for part 2 :-)
I think using a database is the heaviest way of doing this, computationally speaking.