FAT 文件系统和大量写入
我正在考虑将 FAT 文件系统用于嵌入式数据记录应用程序。记录器只会创建一个文件，并每分钟不断地向其中附加 40 字节的数据。使用几年后，写入周期将超过一百万次。我的问题是：FAT 系统是否会在每次附加文件时更改文件分配表？它如何跟踪文件末尾的位置？它只是在末尾放置一个 EndOfFile 标记还是将长度存储在 FAT 表中？如果我每次写入时它都会更改 FAT 表，那么我会在短短几年内将闪存损坏。 FAT 系统是否适合此应用程序？
我的另一个想法是，我可以将原始数据字节存储在存储卡中，并在每次写入时在数据末尾放置一个 EndOfFile 标记。但这不太理想，因为这意味着从记录器中获取数据的唯一方法是通过串行传输，而不是通过 PC 和读卡器。
I am considering using a FAT file system for an embedded data logging application. The logger will only create one file to which it continually appends 40 bytes of data every minute. After a couple years of use this would be over one million write cycles. MY QUESTION IS: Does a FAT system change the File Allocation Table every time a file is appended? How does it keep track where the end of the file is? Does it just put an EndOfFile marker at the end or does it store the length in the FAT table? If it does change the FAT table every time I do a write, I would ware out the FLASH memory in just a couple of years. Is a FAT system the right thing to use for this application?
My other thought is that I could just store the raw data bytes in the memory card and put an EndOfFile marker at the end of my data every time I do a write. This is less desirable though because it means the only way of getting data out of the logger is through serial transfers and not via a PC and a card reader.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
当您修改文件时，FAT 会更新目录表（至少，如果您关闭文件，它会更新，我不确定如果不关闭会发生什么）。这不仅仅是文件大小，也是最后修改日期：
http://en.wikipedia .org/wiki/File_Allocation_Table#Directory_table
如果您的闪存控制器不执行透明磨损均衡，并且您的闪存驱动程序不会重新定位事物以平衡磨损，那么我想你可能会造成磨损。请参阅您的手册，但如果您使用的是消费类硬件，我会认为所有东西都有磨损均衡。
从好的方面来说，如果您担心的事件每分钟都会发生，那么您应该能够在测试中大大加快速度，看看 2 年的日志条目是否真的会破坏您的实际硬件。甚至可能比尝试查找相关制造商文档更快......
FAT updates the directory table when you modify the file (at least, it will if you close the file, I'm not sure what happens if you don't). It's not just the file size, it's also the last-modified date:
http://en.wikipedia.org/wiki/File_Allocation_Table#Directory_table
If your flash controller doesn't do transparent wear levelling, and your flash driver doesn't relocate things in an effort to level wear, then I guess you could cause wear. Consult your manual, but if you're using consumer hardware I would have thought that everything has wear-levelling somewhere.
On the plus side, if the event you're worried about only occurs every minute, then you should be able to speed that up considerably in a test to see whether 2 years worth of log entries really does trash your actual hardware. Might even be faster than trying to find the relevant manufacturer docs...
不，闪存文件系统驱动程序经过明确设计，可以最大程度地减少磨损并将其分散到存储单元中。利用接近零的寻道时间。您的数据速率很低，它将持续很长时间。指定每年更换一次介质是将风险降至最低的简单方法。
No, a flash file system driver is explicitly designed to minimize the wear and spread it across the memory cells. Taking advantage of the near-zero seek time. Your data rates are low, it's going to last a long time. Specifying a yearly replacement of the media is a simple way to minimize the risk.
如果您唯一的操作是附加到一个文件，那么放弃文件系统并使用闪存设备作为数据磁带可能会更简单。不过，您必须考虑闪存的类型及其块大小。
If your only operation is appending to one file it may be simpler to forgo a filesystem and use the flash device as a data tape. You have to take into account the type of flash and its block size, though.
大型闪存芯片分为大小为 264 (256+8) 字节的 2 的幂倍数的子页、为其 2 的幂的倍数的页以及为 264 (256+8) 字节的幂的倍数的块。 - 的两倍。空白页将被视为全部 FF。一次可以写一页；可以写入的最小单位是子页。一旦子页被写入，它就不能被重写，直到包含它的整个块被擦除。请注意，在较小的闪存芯片上，可以单独写入一页的字节，前提是只写入空白字节，但在许多较大的芯片上这是不可能的。我认为在当代芯片中，子页面大小为528字节，页面大小为2048+64字节，块大小为128K+4096字节。
MMC、SD、CompactFlash 或其他此类卡（基本上是除 SmartMedia 之外的任何卡）将闪存芯片与处理器结合在一起，以处理 PC 风格的扇区写入。本质上发生的情况是，当写入一个扇区时，控制器会找到一个空白页，在那里写入该扇区的新版本以及最多 16 字节的“标头”信息，指示它是什么扇区等。然后控制器会保留一个所有不同信息页面所在位置的地图。
SmartMedia 卡直接暴露闪存接口，并依靠相机、读卡器或使用它的其他设备根据标准方法执行此类数据管理。
请注意，跟踪 2 GB 卡上所有 4,000,000 个页面的位置需要具有 12-16 兆 RAM，或者使用 12-16 兆闪存作为辅助查找表。使用后一种方法意味着每次写入闪存页面也需要写入查找表。如果较慢的闪存设备使用这种方法（以便只需要跟踪大约 16,000 个“间接”页面的下落），我一点也不会感到惊讶。
无论如何，最重要的观察结果是闪存写入时间是不可预测的，但您通常不必担心闪存磨损。
Large flash chips are divided into sub-pages that are a power-of-two multiple of 264 (256+8) bytes in size, pages that are a power-of-two multiple of that, and blocks which are a power-of-two multiple of that. A blank page will read as all FF's. One can write a page at a time; the smallest unit one can write is a sub-page. Once a sub-page is written, it may not be rewritten until the entire block containing it is erased. Note that on smaller flash chips, it's possible to write the bytes of a page individually, provided one only writes to blank bytes, but on many larger chips that is not possible. I think in present-generation chips, the sub-page size is 528 bytes, the page size is 2048+64 bytes, and the block size is 128K+4096 bytes.
An MMC, SD, CompactFlash, or other such card (basically anything other than SmartMedia) combines a flash chip with a processor to handle PC-style sector writes. Essentially what happens is that when a sector is written, the controller locates a blank page, writes a new version of that sector there along with up to 16 bytes of 'header' information indicating what sector it is, etc. The controller then keeps a map of where all the different pages of information are located.
A SmartMedia card exposes the flash interface directly, and relies upon the camera, card reader, or other device using it to perform such data management according to standard methods.
Note that keeping track of the whereabouts of all 4,000,000 pages on a 2 gig card would require either having 12-16 megs of RAM, or else using 12-16 meg of flash as a secondary lookup table. Using the latter approach would mean that every write to a flash page would also require a write to the lookup table. I wouldn't be at all surprised if slower flash devices use such an approach (so as to only have to track the whereabouts of about 16,000 'indirect' pages).
In any case, the most important observation is that flash write times are not predictable, but you shouldn't normally have to worry about flash wear.
您是否检查过在设备断电或重置时 FAT 文件系统的一致性会发生什么情况？
当您的设备遇到此类故障时，您不能只丢失您刚刚写入的日志条目。较旧的条目必须保持有效。
不，如果您需要读回数据，FAT 并不合适。
您应该进一步考虑如果闪存充满了数据会发生什么。如何为新数据获取空间？您需要定义这一点的要求。
Did you check what happens to the FAT file system consistency in case of a power failure or reset of your device?
When your device experience such a failure you must not lose only that log entry, that you are just writing. Older entries must stay valid.
No, FAT is not the right thing if you need to read back the data.
You should further consider what happens, if the flash memory is filled with data. How do you get space for new data? You need to define the requirements for this point.