给出的信息太少 不足以判断是哪里的问题。不过不用迷信内核，这么老的内核版本 bug 可不少，我们做存储碰上过一篮子的各种内核 bug

入职时新员工培训就应该说清楚了

作为新手参与社区的第一步，提 fix typo 也正常。但这个营销...

即使是 mv 这样看起来很简单的 command tool ，做的工作也比想象中得多，和 syscall 肯定不是一个粒度的，这个 case 里你用 strace 来跟踪下 mv 产生的 syscall 就知道了。

mv 先会尝试去直接 rename 到 dir 这个目录上，但是 syscall 报错 file exists
renameat2(AT_FDCWD, "test-file", AT_FDCWD, "dir", RENAME_NOREPLACE) = -1 EEXIST (File exists)

mv 应该特殊处理了这个错误，第二次会尝试 rename 到 dir/test-file
renameat2(AT_FDCWD, "test-file", AT_FDCWD, "dir/test-file", RENAME_NOREPLACE) = 0

@stillsilly 赞同，楼主才刚毕业，35w 也许不多，钱可以还完，但人无再少年

Rust 又赢了

云厂商这些 SDK 基本都是生成或外包随便写的，根本没人去管，质量差的很

@tool2dx 我觉得没啥问题，文件系统的空间分配和管理没那么简单。回收站这个东西也不适合由文件系统来实现，应该由业务层（文件管理器等）来做

+1 ，我是在微信点开视频的时候很容易破音，用过的 15, 19, 21 款的 MBP 都是这样，感觉是通病。不过最近好像很少出现了，不知道是不是更新了 macOS 15 的缘故

自带的「屏幕共享」就很好用

都是“开源”，但不同方式之间差异很大

有一些是软件本身开源但不接受贡献 or 不维护社区，这种就只是公开代码而已，开发都在内部仓库，每次发版后就直接往 Github 上的仓库提个只有一条 commit 的上万行 pr 完事。

大部分商业项目开源都是将组件设计为可插拔的，高级功能的组件是单独维护的，这样核心部分可以按正常的开源项目来维护和管理社区。或者内核完全开源，但产品化功能（例如管控平台、云服务）闭源，就我接触到的数据库、存储开源项目而言大多是这样

@imes 生态不够成熟，语言本身也在快速发展，经常有新特性和新设计模式冒出来，所以被 Rust“重写一切”的也包括这些库自身

@xue777hua 写过 Rust 就知道，nightly 才是真正能用的，Databend, TiKV, RisingWave... 这些大规模生产使用的项目都是要 nightly toolchain 编译的，我反而找不到几个不用 nightly 的非玩具项目

用 Rust 做过分布式数据库和存储引擎，比 cpp 体验好太多了... Rust 最主要的问题是招人难； 其次是生态上各种库永远是 0.x 版本，每次一升级依赖 一大堆 breaking change ，包括语言本身不上 nightly 也一堆特性没法用

share 下 JuiceFS 的一篇文章，有提到对 Go 做的内存优化：[极限挑战：使用 Go 打造百亿级文件系统的实践之旅]( https://juicefs.com/zh-cn/blog/engineering/go-build-billion-file-system)