逮獭科技22-5-23 21:04

逮獭科技22-5-23 21:04 #btrfs 始于一个copy on write的简单想法,这个概念现在前端也非常熟悉,immutable嘛,把文件搞成文件块链表,关闭时创建新版本,写入设计尽可能具有局域性而不是大范围的移动指针读写,好的文件结构设计应该如此,log,数据库,等等。 你能在phoronix上看到btrfs的第一次mainline的时间是2009年。 后来脸书突然发现自己需要一个文件系统。最好能像zfs那样有一些时髦特性,但不要像zfs那样消耗系统资源,当然,消耗资源越少越好,但文件或文件系统的版本管理是重要的。他们选择了btrfs,并且把主力开发人员Chris Mason招至麾下。这是2013年前后。 btrfs-send是这个文件系统的招牌特性,这个特性的稳定成熟就在这个时期。 这里可以向不太熟悉文件系统的朋友介绍下它为什么重要。在真正「热」的存储系统中,没有任何一个时刻所有文件都close了,给文件系服务一个「恰当」的时间点snapshot整个文件系统的状态,比如做backup,以后恢复回来。这是为什么文件系统的版本管理要在block level做的原因。在block level,如果文件系统实现允许,可以找到一个时间点flush所有尚未写入的缓存,然后标记一个disk image意义上的snapshot,这不意味着所有的文件都是完整的,但具有版本管理的文件系统,它至少有一个文件的上一次副本;而且如果snapshot实现的足够轻量,就可以高频snapshot,这样即使是那些在打开写入的文件,也有很大几率恢复出足够好的可用版本;这是故事的一半。 故事的另一半是,你还得足够高效的把每一次的修改copy出来,这个copy的IO次数越少越好。btrfs-send就是在底层做这件事,你调用API,它一次性的把两个版本之间的diff拖出来,通常走网络发送到另一个机器上,这样实现增量备份,要复原时把一长串Delta一个一个patch回来。 这种文件系统的用途不难想象。btrfs算穷人版的zfs,一个资源消耗有限的子集。 再后来一个时期,facebook需要的功能都做得不错了,包括性能和稳定性,但是社区里各种corner case的性能和稳定性问题层出不穷,Facebook没有全面维护,很多bug修复缓慢,工具也经常有问题。群晖就在btrfs这种质量时给开放给用户的,它也没什么好办法。 再后来一个时期btrfs突然迎来华人维护者生力军,你仔细看开发者邮件地址,会发现他们都是来自南京富士通。不知道富士通在什么产品上用了btrfs,雇佣了不少年轻人写btrfs驱动。在很大意义上也说明了btrfs的维护不需要super engineer,只需要永远站在那儿为代码质量负责的人。当然,人都是要吃饭的。后来可能富士通不再为用户提供基于btrfs的产品了。经过一个时期的活跃,各种拍bug,维护又回归沉寂。 现在btrfs维护不温不火。Kernel里常看到patch,但针对的use case越来越罕见;说明它作为一个文件系统,主要目标都大体完成,趋于稳定。但不是说它就完美了,实际上btrfs错过一个非常好的机会,就是Google开发人员曾经在mailing list里问btrfs的加密能力如何,得到的答复是btrfs没有特殊的加密设计,仅支持Kernel的block层的通用加密框架。Google对这个设计不满意,btrfs错过了成为Android的rootfs的宝贵历史机会。 说到btrfs,还有一个人值得提及;这个人名字叫Kent Overstreet,肯特过街,很好记。 KO象Mason一样幸运被大公司招进去了,他去了Google,但不幸的是,Google没有给KO大展拳脚的机会,即使他是bcache的作者。KO非常熟悉Kernel里block level cache怎么做,框架是通用的,可以用ssd加速任何文件系统,也包括LVM。 而且KO也对copy on write感兴趣。他做了一个叫bcachefs的文件系统,有btrfs里最重要的功能部分,代码只有btrfs的一半左右,据说结构上比btrfs好很多。bcachefs 解决了btrfs的一个重要问题,就是后者读写时不区分ssd还是hdd,这对大型存储单元来说可能没什么意义,但是对个人用户来说这可是宝贝啊。 后来KO离开了Google,自己一个人维护着bcachefs。应该是日子经常过的紧巴巴的,因为曾多次为bcachefs募资,募资目标,以中国码农收入标准去看都算少的,还经常募不足。但他还是一个人维护这个文件系统。你要是有一段时间觉得自己电脑上rootfs的稳定性不那么重要(指经常备份),可以考虑支持一下KO,装一个bcachefs文件系统并且把遇到的bug或者性能问题告诉他。bcachefs有一个很小的用户基数,据用户说稳定性很好了。

相关推荐

封面图片

原来这些“已删除”的文件可能一直都在这些设备上

原来这些“已删除”的文件可能一直都在这些设备上 在向 9to5Mac 详细说明这个问题时,苹果表示这是由设备文件系统上的一个损坏的数据库条目引起的,这影响了设备本身的文件,而不影响那些已经同步到 iCloud 的文件。这些文件可能是在从备份恢复或在设备间传输时从旧设备带过来的。 一位 Reddit 用户曾在一篇现已删除的帖子中声称,iOS 17.5 的一个错误导致一台已经被清除数据并卖给朋友的 iPad 上的照片重新出现。然而,苹果公司否认这种情况的可能性,他们对 9to5Mac 表示,一旦设备的数据被彻底清除,所有文件和内容都会被永久删除。本质上,苹果公司认为这位用户要么没有按照正确的设备重置程序操作,要么只是为了在 Reddit 上博取关注而撒谎。该公司表示,只有少数人受到数据库问题的影响,并且苹果公司无法访问用户手机上的照片或视频文件。 Synacktiv 的安全研究人员通过对 iOS 17.5.117.5 增加了一个迁移程序,负责扫描文件系统并重新导入照片。由于这个程序导致旧文件在本地文件系统中重新索引并重新推回到相册中,苹果在最近的更新中删除了这个程序。 根据这段代码,我们可以说,那些重新出现的照片仍旧存放在文件系统中,只是在 iOS 17.5 中增加的迁移程序找到了它们,”Synacktiv 表示。“仅凭这个分析,我们无法得出这些照片最初是如何留在文件系统中的结论。”接着,Synacktiv 的文章引导读者查看 Reddit 上的这条评论,以获取一个合理的解释,其中包括用户可能将图片同时保存到文件应用和照片应用中,但只删除了后者的可能性。 标签: #Apple #iOS 频道: @GodlyNews1 投稿: @GodlyNewsBot

封面图片

Linux Kernel 6.8正式版发布 更新LAMP虚拟化以及对龙芯提供Rust支持

Linux Kernel 6.8正式版发布 更新LAMP虚拟化以及对龙芯提供Rust支持 6.8 版的一些亮点功能包括:LAM / 线性地址屏蔽的虚拟化支持KVM 的来宾优先内存支持更新 Bcachefs 文件系统的基本在线文件系统检查和修复机制对树莓派 5 使用的博通 BCM2712 芯片提供支持基于 AMD ACPI 的 WiFi 频段 RFI 缓解功能zswap、CephFS 等功能优化针对龙芯架构的 Rust 初始支持:从 6.8 版开始 Linux Kernel 在龙芯架构 (LoongArch) 上提供了初始 Rust 支持,UFFDIO_MOVE uABI 操作允许页面在虚拟地址空间内移动,同时可以避免由 UFFDIO_COPY 完成页面分配和 memcpy。KSM 顾问功能可以自动管理内核相同页面合并子系统,支持用于 SMB 文件系统创建块和字符特殊文件,而用于创建网络的 PHY 驱动程序已经获得 Rust 的初始支持。目前一般认为 Rust 语言的安全性更好,因此包括 Linux 和 Windows 都在逐渐使用更多 Rust 编写模块。支持周期方面:Linux Kernel 6.8 版是一个非 LTS 版,它的支持周期只有几个月,之后会被 Linux Kernel 6.9 版接替。目前 Linus Torvalds 已经开启了 Linux Kernel 6.9 版的合并窗口,6.9 版预计是在 2024 年 5 月中旬发布。相关文章:Linux 6.8 稳定版发布 新增Intel Xe图形驱动程序 ... PC版: 手机版:

封面图片

一个新开发的macOS上的SSH客户端

一个新开发的macOS上的SSH客户端 特征 免费和开源 支持 libssh2 的主机连接 Linux proc 文件系统状态信息 使用密码、密钥等进行身份验证... 支持 xterm 的终端 批处理执行的代码片段

封面图片

"快照(Snapshot)"是数据库领域非常重要的一个概念, 最初是用于数据备份. 如今, 快照技术已经成为数据库内核(引擎)最

"快照(Snapshot)"是数据库领域非常重要的一个概念, 最初是用于数据备份. 如今, 快照技术已经成为数据库内核(引擎)最核心的技术特性之一. 数据库内核的绝大多数操作, 都依赖于快照, 例如, LevelDB 的每一次读取操作和遍历操作, 其内部都必须创建一个快照, 所以, 对于一个请求量非常大的系统, 数据库内核每秒种就要创建和销毁几十万次快照. 因此, 如何快速地创建和销毁快照, 成为一个数据库内核(引擎)必须要解决的问题. 本文从源头出发, 逐步推演, 探讨数据库内核是如何实现快照技术的. 数据库内核创建快照, 将使用如下技术: 全量拷贝(Full Clone) 写时拷贝(Copy On Write) 分区拷贝(Partitioning) 多版本(Multi Versioning, Leveling, Zero Copy)

封面图片

【Amber Group公布其研发的首个NTFS3模糊测试框架】

【Amber Group公布其研发的首个NTFS3模糊测试框架】 近日,信息安全行业顶级盛会2023年亚洲黑帽大会(Black Hat Asia 2023)在新加坡圆满落下帷幕。加密金融服务提供Amber Group合伙人兼Web3安全团队负责人吴家志博士和研究员罗元琮在大会中公开了其研发的首个NTFS3模糊测试框架,分析NTFS3文件系统中存在的缺陷和根本原因,以全新视角检视Linux操作系统内NTFS3文件系统的安全性。 Amber Web3安全团队与北京大学合作展开联合研究,以调查Linux系统中存在的漏洞和根本原因。使用他们自己开发的Papora模糊监测框架,该团队识别了NTFS3文件系统中12个零日漏洞;其中9个漏洞补丁已在Linux v6.2发布,另外3个漏洞补丁也已经被文件系统维护者接受。这项重要成就也得到了2023年攻击技术研讨会(WOOT’23)的认可。

封面图片

已删除的 iPhone 照片为何会返回到某些 iOS 设备?

已删除的 iPhone 照片为何会返回到某些 iOS 设备? 苹果公司向 9to5Mac 详细解释了这个问题,称这是由于设备文件系统上的数据库条目损坏造成的,影响的是设备本身的文件,而不是那些已经同步到 iCloud 的文件。这些文件可能是在从备份恢复或设备间传输过程中从旧设备上转移过来的。一位 Reddit 用户曾在一篇现已删除的帖子中称,iOS 17.5 的漏洞使一台 iPad 上的照片重新出现,而这台 iPad 已被清除并卖给了朋友。然而,苹果公司声称这是不可能的,它告诉 9to5Mac,一旦设备的数据被完全清除,所有文件和内容都将被永久删除。从根本上说,苹果声称这位用户要么没有遵循正确的设备重置程序,要么只是为了在 Reddit 上获得影响力而撒谎。该公司表示,只有少数人受到数据库问题的影响,而且苹果也无法访问用户手机上的照片或视频文件。Synactiv 的安全研究人员还通过逆向工程对用于修复该问题的 iOS 17.5.1 更新进行了扩展。你可以在他们的完整报告中找到详细解释,但简而言之,iOS 17.5 增加了一个迁移例程,负责从文件系统中扫描和重新导入照片。苹果最近的更新删除了该例程,因为它会导致旧文件在本地文件系统中被重新索引,并推回到照片库中。Synacktiv 说:"根据这段代码,我们可以说,重新出现的照片仍在文件系统中,它们只是被 iOS 17.5 中添加的迁移例程找到了。"仅凭这一分析,无法断定这些照片当初是如何留在文件系统上的。Synacktiv 的文章随后引导读者查看 Reddit 上的这篇评论,以获得一个合理的解释,其中包括用户可能同时将图片保存到文件应用和照片应用中,但只删除了后者。阅读报告全文: ... PC版: 手机版:

🔍 发送关键词来寻找群组、频道或视频。

启动SOSO机器人