[SPDK] Re: Bad Sectors / expected 'error' responses & timing
松本周平 <shuheimatsumoto at gmai l.com>
| Newsgroups | dev.linux.lists.spdk |
|---|---|
| Message-ID | <CAFEtCnCqiRTj4=FugDwtoWDnOteBKbZ5nTfknMdbkqAWRX+pFA@mail.gmail.com> |
Hi Alvar, Thanks for sharing your exciting project and your interest in SPDK. About detecting bad sectors, how about end to end data protection (e.g. T10 DIF) ? Please take a look at the section 8.3 of NVMe specification. https://nvmexpress.org/wp-content/uploads/NVM-Express-1_4a-2020.03.09-Ratified.pdf Please also take a look at https://en.wikipedia.org/wiki/Data_Integrity_Field SPDK NVMe API supports this feature. I think end to end data protection may satisfy your requirement but I'm not certain yet. Others may be able to provide better information. Thanks, Shuhei On Sat, Jun 20, 2020 at 3:08 AM <alvarso(a)mit.edu> wrote: > Hello SPDK team, > > First, thank you for the really cool work you are doing! I am working on > a small satellite mission at MIT, which will use a 6-channel SDR (SW > defined radio). My task is to ensure that the 6-channel SDR data is saved > reliably to an SSD. I am working on the processor (PS) side. Another > colleague is working on the FPGA PL (programmable logic) side. The FPGA > will provide DMA (still under development). > > My general idea to try to achieve zero-copy performance is: > > ADC -> PL Queue > PS Determines SDRAM temporary storage > DMA from PL Quque -> SDRAM (likely using libiio) > PS Determines when a block (or other storage unit, TBD) is ready to go > to SSD > -> because our data is always the same size/format, I believe we can > use an analytic/deterministic equation to determine the storage location > DMA from SDRAM -> SSD (likely using SPDK) > > when its time to 'process' the data (which has to be at a later time due > to power limits of the satellite): > > PS determines (analytic equation) data to be processed > DMA from SSD -> SDRAM (w SPDK) > PS informs PL of data vailable > PL processes data via DMA > PL informs new 'processed data queue' ready > PS prepares location for processed data > DMA from SDRAM -> SSD (w SPDK) > > The mission PI (principal investigator) has one main worry of our > approach: he is concerned that SSD's can end up with 'bad sectors', like > older drives, but that its usually a big chunk of space that goes bad. We > are not concerned about single-event-upsets (when just one individual piece > of data gets damaged), but rather when a large section that can result in > us loosing too much data. > > I understand that the idea of keeping track of 'bad sectors' in 'hard > drives' is usually the task of a file-system. However, for our purposes a > file system is appearing to be too much overhead and we have not found one > that would help us with a 'zero copy' setup. But we need to be able to know > when there are data errors (read data is garbage) and not slow down if > there is a bad write request (if a bad write slows down the system, then we > loose 'new' data that should have been saved). > > I read the documentation as much as possible, and did a good amount of > online searching for the 'expected' response from SPDK when the SSD has > errors. But I could not find any information on that. I would greatly > appreciate if anyone in the team can guide me in the right direction (maybe > its pointing to some standard that SPDK adheres to [NVMe & PCIe] but even > that I was not sure how SPDK returns such errors and the expected timing of > them). > > Hopefully this was clear and its in the scope of this list; if its not, > please ask me to clarify or I greatly appreciate if you point me in the > right direction. > > Thank you! > > Alvar > > PS, Summary: > - Trying to do zero-copy 6-channel data saving from FPGA to SSD (PCIe NVME) > - If I don't want a full file-system, how can I handle 'bad sector' type > errors in the SSD? > - Is there any spec of expectation on the timing impacts when an error > occurs? > _______________________________________________ > SPDK mailing list -- spdk(a)lists.01.org > To unsubscribe send an email to spdk-leave(a)lists.01.org >