页次: 1
创建了一个文件a.img,做成EXT4文件系统,然后挂到/mnt,然后执行cp a.img /mnt/kj
奇怪的事情来了,文件有400MB左右,但复制过程只花了一秒不到。而且复制成功了,没有报错。
卸载再重新挂载/mnt,发现还是正常的,a.img这个文件系统下面确实存在名为kj的文件 ,但是ls显示/mnt/kj和a.img大小一样,怎么回事?
文件系统总共就400MB,怎么还放的下400MB的文件?
反社会,精神极其不稳定,随时可能炸碎身边所有人
离线
空洞?
离线
空洞?
好吧,du发现了,两个文件都有大量空洞
那么如果以后向/mnt/kj写入非零数据,写满400MB的话,保存文件的时候应该就会提示文件系统空间不足了吧。
不过由此引来的问题就是,du的行为略奇怪,它用来显示文件所占块数量。可是他不去读取文件系统的block大小而是依靠命令行参数或者环境变量来指定,否则默认1024,所以不加参数的化,显示出来的值很可能和真实文件系统情况不符。
反社会,精神极其不稳定,随时可能炸碎身边所有人
离线
百合仙子 说:空洞?
好吧,du发现了,两个文件都有大量空洞
那么如果以后向/mnt/kj写入非零数据,写满400MB的话,保存文件的时候应该就会提示文件系统空间不足了吧。
不过由此引来的问题就是,du的行为略奇怪,它用来显示文件所占块数量。可是他不去读取文件系统的block大小而是依靠命令行参数或者环境变量来指定,否则默认1024,所以不加参数的化,显示出来的值很可能和真实文件系统情况不符。
是写入数据的时候会返回文件系统已满的错误,但是是否告诉用户就不一定了,比如 Sublime Text 会安静地忽略这个错误并且认为文件保存成功。
你把 du 的块当成一种单位好了。很多程序都这么干,比如 ls 和 dd(而且它们的默认大小还不一样……)。
离线
页次: 1