最好的方式来“硬化”embedded式ext4文件服务器,防止意外的电力损失?

首先,有一点背景:我公司生产的audiostream设备是一个无头的机架式Linux机箱,附带一个Solid State e-SATA驱动器。 驱动器格式化为ext4。 用户可以使用Samba / CIFS连接到系统来上传新的audio文件或访问现有的audio文件。 还有通过networkingstream出audio的自定义软件。

这一切都很好。 唯一的问题是,用户是audio人,而不是电脑人,并将系统视为“黑匣子”,而不是电脑。 这意味着在一天结束的时候,他们不打算进入框中input“/ sbin / shutdown -h”; 他们只是要切断机架的电源而离开,并希望第二天能继续正常工作。

由于ext4有日志logging,日志校验和等,所以大多数情况下是可行的。 唯一不行的是当有人通过Samba上传一个新文件,然后在上传数据完全刷新到磁盘之前切断系统的电源。 在这种情况下,他们在第二天进来,发现他们的新文件已被截断或完全丢失,并且不高兴。

我的问题是,避免这个问题的最好方法是什么? 有没有办法让smbd在每次上传结束时都调用“sync”? (上传效果不是那么重要,因为它们只是偶尔发生)。 或者是否有办法告诉ext4在几秒钟内自动刷新文件的任何改变? (同样,为了安全起见,可能会牺牲性能)我应该设置特定的写入顺序模式,激活屏障等吗?

使用fstab中指定的sync装载文件系统可能会有所帮助。 我怀疑有人会有更适合您的特定应用的build议。

我开始对用于闪存存储的文件系统进行初步研究,因为我想定制一个家庭影院PC作为设备。 您可能会发现更适合您设备的不同存储解决scheme。 不幸的是,我还没有find我喜欢的东西,所以我没有一个详细的build议。

编辑1

根据smb.conf(5)联机帮助页,它支持SAMBA中的即时同步:

  strict sync (S) Many Windows applications (including the Windows 98 explorer shell) seem to confuse flushing buffer contents to disk with doing a sync to disk. Under UNIX, a sync call forces the process to be sus- pended until the kernel has ensured that all out- standing data in kernel disk buffers has been safely stored onto stable storage. This is very slow and should only be done rarely. Setting this parameter to no (the default) means that smbd(8) ignores the Windows applications requests for a sync call. There is only a possibility of losing data if the operating system itself that Samba is running on crashes, so there is little danger in this default setting. In addition, this fixes many performance problems that people have reported with the new Windows98 explorer shell file copies. Default: strict sync = no sync always (S) This is a boolean parameter that controls whether writes will always be written to stable storage before the write call returns. If this is no then the server will be guided by the client's request in each write call (clients can set a bit indicat- ing that a particular write should be synchronous). If this is yes then every write will be followed by a fsync() call to ensure the data is written to disk. Note that the strict sync parameter must be set to yes in order for this parameter to have any affect. Default: sync always = no 

对,我一直在处理同样的问题。 如果在系统中禁用任何types的写入caching,则任何数据将尽快写入磁盘。

你将失去性能,但你会得到更好的数据完整性。

磁盘上的数据和操作系统认为在磁盘上的差异(但实际上caching在内存中)将显着降低。

如果你不能使用UPS作为解决scheme,或者一些硬件解决scheme,优雅地closures机器,如果AC掉电,那么你将不得不使用黑客这样的黑客。

使用更简单的文件系统来存储媒体,以及从虚拟盘启动操作系统可能是一个想法。 从而避免破坏机器的启动/根分区的机会。

所以回顾一下,

使用同步装载文件系统,您将失去性能,但所有写入都不会被caching。

closures硬盘写caching,再次失去性能。

这篇文章应该是你感兴趣的

http://sr5tech.com/write_back_cache_experiments.htm

既然你提到你的公司build立这些,我build议看一下硬件angular度。 我已经在驱动器控制器上看到了带有电池备份的服务器,以允许caching数据在电力不足的情况下继续运行。 如果您的工程师使用小电池来保持系统运行时间足够长以closures干净,会怎么样? 它不需要是一个大的,单独的UPS,它可以是内部的,并且在A / C电源丢失时立即closures系统。 这可能会增加几美元的成本,但它也可能是一个营销点。