日志文件系统（journaling file system）是一个具有故障恢复能力的文件系统，在这个文件系统中，因为对目录以及位图的更新信息总是在原始的磁盘日志被更新之前写到磁盘上的一个连续的日志上，所以它保证了数据的完整性。当发生系统错误时，一个全日志文件系统将会保证磁盘上的数据恢复到发生系统崩溃前的状态。同时，它还将覆盖未保存的数据，并将其存在如果计算机没有崩溃的话这些数据可能已经遗失的位置，这是对关键业务应用来说的一个很重要的特性。
并不是所有的操作系统都提供了同样的日志技术。Windows NT提供了一个完整系统的不太健壮的版本。如果你的Windows NT系统崩溃了，你可能不会丢失整个磁盘卷，但你可能会丢失系统崩溃前没写到磁盘的所有数据。出于同样的原因，缺省的Linux系统，ext2fs，根本没有登记日志。这就意味着，一旦系统崩溃——虽然在Linux系统中不常见——就会毁坏整个磁盘卷。
NTFS是日志式文件系统，U盘\闪存卡的储存芯片读写次数是有限的
使用NTFS系统的话，意味着所有对磁盘的操作都要记录日志。
大量的小文件读写对于U盘寿命有影响。NTFS做日志记录那点开销谈不上伤吧 大容量的、对数据一致性有要求的、一直挂载在设备上的应该用有日志的文件格式 exfat容易丢数据 适合只用来临时几个文件拷过来拷过去的用途 像拔下来要win上插过mac再插的话很容易读不出来 经常要手动fsck
扔了最合理
smr叠瓦式硬盘最合理的使用方法，是当成CD-RW光盘用。
很多年轻的朋友都没经历过光盘当红的年代，2010年后电脑上的光驱都开始淘汰了。
CD光盘分3类：
一种叫CDROM，是只能工厂刻录，用户买回来只能读不能写，通常用来印刷正版软件和影音、游戏。我们平时买到的亮银色的盗版光盘就是这种。
一种叫CD-R，是内容空白的，用户买回来后只能写入一次，然后就只能读取不能再写入，就跟白纸一样，拿钢笔写过字了就只能看，擦不掉了。
最后一种叫CD-RW，也是空白的，用户买回来后能多次写入和擦除，但每次擦除会损伤光盘涂层，通常擦十几次（国产劣质）到百多次（飞利浦原装）就不能用了。就好像拿铅笔在白纸上写字，用橡皮擦可以擦，但擦几十次纸就烂了。
smr叠瓦式硬盘的擦写特性，就很像完美品质的CD-RW，擦写几千次应该没问题，但跟普通硬盘的几十万次寿命没得比。
所以使用时我建议减少写入次数，也就是只往里面存，不删除。过个一年半载，再买一个硬盘将文件全盘复制过去，然后格式化旧盘，又能当新的用。
用支持cow的文件系统，比如REFS，btrfs，叠瓦虽然写入慢，但是读快。
买条16g傲腾插电脑上加速。
避免做raid，raid重建妥妥报废
经常混合读写，做好硬盘报废准备
SMR盘有好几种,一种带TRIM,一种不带TRIM,带TRIM还好说,不带TRIM你大文件拷多了照样掉速到40m/s
理论党，未经验证，欢迎各位6大佬指正。
SMR的原理就不重复了，简单来说就是因为改写操作麻烦，导致覆盖写入性能低下，并且容易因为扇区映射表的频繁更新导致磁盘故障。
所以，理论上如果用于覆盖写入少的场景，就能较大程度的避免SMR的这个缺点。哪些场景的覆盖写入少呢？我个人认为使用具备COW(Copy On Write，写时复制)特性的文件系统就可以很好的满足这个要求，例如ReFS、ZFS、BtrFS。
当然，即使是cow的文件系统，也是必须要有充裕的未使用空间，才能尽可能避免产生覆盖写入操作。过多的分区会导致未使用空间变小，并不利于文件系统充分利用未使用扇区。
talk is cheap 关注他 76 人赞同了该文章 说明：本文示例基本来自CRASHCONSISTENCY: FSCKANDJOURNALING。 位于磁盘上的文件系统需要面临的一个问题是：当系统crash或者意外掉电的时候，如何维持数据的一致性。比如现在为了完成某项功能，需要同时更新文件系统中的两个数据结构A和B，因为磁盘每次只能响应一次读写请求，势必造成A和B其中一者的更新先被磁盘接收处理。如果正好在其中一个更新完成后发生了掉电或者crash，那么就会造成不一致的状态。 假设一个文件系统在磁盘上的分布是这样的：其中包括一个文件的inode（即I[v1]），data block（即Da）和记录分配状态的inode bitmap, data bitmap。日志型文件系统 - 原理和优化
现在要在文件末尾追加一部分内容，那么需要分配一个新的data block（即Db），这会导致inode和data bitmap都发生相应的变化。
因此需要对磁盘的三个不同位置（3个blocks）分别进行写操作，如果在这三次写操作的间隙发生了crash，那么可能出现若干种情况：只更新了其中一个部分，或者只更新了其中的两个部分。
传统的Unix系统对此的解决办法是使用fsck工具，但是fsck通常需要在发生crash重启后，扫描整个磁盘，繁琐且速度较慢，因此目前更流行的做法是使用日志（Journaling）。
日志型文件系统的基本思想是这样的：在真正更新磁盘上的数据之前，先往磁盘上写入一些信息，这些信息主要是描述接下来要更新什么，相当于 wrtie ahead，因此这种方式又被称为write-ahead logging。
这样，即便发生crash，也可通过记录的日志信息，回溯并恢复crash前正在进行的操作（称为replay）。在更新的时候增加一点额外的操作，换来了recovery时所需的工作量的减少。
在Linux中，ext2文件系统将磁盘划分成若干个block groups，每个block group包含一个inode bitmap, data bitmap, inodes和若干个data blocks，它没有使用日志。
而在ext3文件系统中，加入了对日志的支持，日志部分单独占据一块磁盘空间。
还是前面那个例子，现在我们要更新磁盘上的inode（I[v2]）, bitmap（B[v2]）和data block （Db）。在更新这个数据之前，我们把这个更新操作的步骤（称为一个 transcation），加上分别表示这个transcation开始和结束的TxB和TxE，写入磁盘。
Transaction的概念起源于数据库领域，它有助于在操作未能完成的情况下保证数据的一致性。同一transcation的TxB和TxE具有相同的sequence number。
在一个记录步骤信息的transcation完成之后，才真正地更新磁盘上的文件数据（这一步称为checkpoint）。
Journal是为了保证数据一致性的，而journal本身也是由多个部分组成，那在写入journal的过程中发生了crash怎么办？由于I/O scheduling等原因，各个部分不一定是按照提交的顺序写入的（out of order），那么可能出现下图所示的这种情况：缺少了Db，但TxB和TxE都存在，系统恢复的时候会误以为这是一个完整的transcation。
解决的办法是使用write barrier。写入除TxE以外的部分后（这一步叫做 journal write），执行一次barrier操作（对于支持journal checksum的ext4文件系统，此步骤可省略）。如果在此期间crash了，由于没有TxE，这个transcation会被认为是不完整的，重启后就不会试图恢复这个transcation所代表的步骤。
待journal write顺利完成以后，再写入TxE（这一步叫做 journal commit），然后再执行一次barrier操作，以保证数据的写入是发生在journal完成之后（write barrier在保证数据一一致性的同时，会不可避免地对性能造成影响，如果能够接受不使用barrier带来的潜在风险，可以在mount文件系统的时候使用"nobarrier"选项）。
因此，在日志型文件系统中，一个完整的数据写操作由"journal write"，"journal commit"和"checkpoint"三部分组成。写操作完成后，就可以释放journal本身所占据的磁盘空间了。
至此，涉及多个block的写操作的数据一致性问题算是有了保证，但这基于的是一个block的数据要么完全写了，要么完全没写的前提，那会不会出现一个block的数据只写了一部分的情况呢（half-written）？这其实是一个原子性的问题，由磁盘本身提供保障，即对一个block的操作必须是原子的（不可分割的）。
journal好是好，不过要多做的工作也是显而易见的，别的不说，磁盘的I/O负载首先就会蹭蹭地上升。那有什么办法可以优化吗？（此处的「优化」是真的优化哈，不是公司裁人的那种所谓“优化”）。
一种比较容易想到的方法是将多个journal的操作进行聚合处理，这种batching的思想在软件设计中也是随处可见的。结合到日志型文件系统自身的过程，还可以将journal中对"Db"的记录移除，即journal中只包含对inode和bitmap更新的记录。
此时，write barrier只能保证对meta data（包括inode和bitmap）的真实写操作发生在journal的写操作之后，由于磁盘写操作的out of order特性，user data的真实写操作则可能发生在此过程中的任何节点，这种模式被称为"Writeback"。
允许out of order对性能的提升当然是有裨益的，但如果crash是发生在journal写操作之后，meta data的真实写操作之前（假设也在user data的写操作之前），那么进行文件系统的recover时，meta data的写操作会被replay，但是user data的写操作不会，这将有可能造成同一文件的meta data和user data的不一致（图1左侧部分）。
不过呢，Writeback模式相对完全不用journal的模式，造成不一致的概率降低了，不一致带来的危害也降低了，作为性能和稳健的平衡，还是有相当的可取之处的。如果想把稳健性再提高一点呢，就再多做出一点限制：即保证对user data的真实写操作发生在journal的写操作之前，这就是"Ordered"模式（图1中间部分）。
对于Ordered的模式，如果crash发生在user data的写操作之后，journal的写操作之前，那么将造成这一部分user data的丢失，不过不会造成不一致的问题。如果crash发生在journal的写操作之后，meta data的真实写操作之前，那么完全可以通过replay来还原。
可见，从"Writeback"模式，到"Ordered"模式（同为Metadata Journal），再到本文最开始介绍的基本模式（Data Journal），数据丢失和不一致的风险是依次降低的，而对性能的损耗则是依次升高的。现代的文件系统通常会提供多种模式的选择，供不同场景下的用户使用。
参考：
原创文章，转载请注明出处
联系客服
