CrLf

45# Batcher


！！磁盘缓存...

qzwqzw

46# zm900612
已经试验证实文件逻辑存储顺序与文件系统有关
对一个磁盘分区先后格式化为NTFS、FAT32、exFAT三种FS格式
拷入以下脚本文件反复测试文件逻辑存储的偏移
结果发现在同一台PC上
NTFS总是具有明显的偏移
FAT32和exFAT则几乎没有
另外发现NTFS下文件写入的速度的明显快于FAT32/exFAT
推测正因为NTFS采取了更为高效的缓存机制
所以一方面导致文件读写性能大幅提升
另一方面导致文件的逻辑存储顺序随机化

@echo off & setlocal EnableDelayedExpansion
for /l %%i in (1,1,300) do echo.A>%%i.xxx
set maxoffset=0
set minoffset=0
for /f %%f in ('dir /a-d /b /od *.xxx') do (
	set/p=%%f <nul
	set /a count+=1
	set /a offset=%%~nf-count
	if !offset! gtr !maxoffset! set maxoffset=!offset!
	if !offset! lss !minoffset! set minoffset=!offset!
)
echo.
echo ----------- %minoffset% : %maxoffset% -----------------
pause
del *.xxx
复制代码

CrLf

46# zm900612
已经试验证实文件逻辑存储顺序与文件系统有关
对一个磁盘分区先后格式化为NTFS、FAT32、exFAT三种FS格式
拷入以下脚本文件反复测试文件逻辑存储的偏移
结果发现在同一台PC上
NTFS总是具有明显的 ...
qzwqzw 发表于 2011-5-20 10:56

看来有结论了，嘿嘿

michael8111

48# zm900612


还有“推测”二字……
目前还无法证明：NTFS是否会导致文件的存储顺序随机化

mxxcgzxxx

要想有结论看来要去专业硬件论坛咨询了！

plp626

fastlz说，wmi 。。。。

一针见血。。。

qzwqzw

51# plp626
辞不达意
看不出跟上下文有什么关联

fastslz

用wmi获取的文件写入时间FAT32,exFAT可以精确到100毫秒以内，NTFS可以精确到100000毫秒以内，应该是这些信息决定了它的排列方式
我这里xp和Windows7排列方式一样的，所以不应该存在BUG
每台电脑排列方式不一样可以这样解释，比如用for创建300个文件奔3级CPU创建可能所需时间更长

@echo off
:测试方法放在不同文件系统的根目录下
set adir=%~d0
ver|find "5.1"&&set v=5.1
ver|find "6.1"&&set v=6.1

if defined v (
md %adir%\%v%-Test 2>nul
if not exist %adir%\%v%-Test\*.txt for /l %%i in (1,1,300) do cd.>%adir%\%v%-Test\%%i.txt
)

for %%i in (5.1,6.1) do (
if exist %adir%\%%i-Test\*.txt (
Wmic Datafile Where "Extension='txt' and Drive='%adir%' and path='\\%%i-Test\\'" get CreationDate,name>%%i-Test-%v%-wmi.txt
dir /a-d /b /od    %adir%\%%i-Test\*.txt>%%i-Test-%v%-od.txt
))
复制代码

引用NTFS百度百科

对DOS略知一二的读者一定熟悉文件的各种属性:只读、隐藏、系统等。在NTFS文件系统中，这些属性都还存在，但有了很大不同。在这里，一切东西都是一种属性，就连文件内容也是一种属性。这些属性的列表不是固定的，可以随时增加，这也就是为什么你会在NTFS分区上看到文件有更多的属性. 　　
NTFS文件系统中的文件属性可以分成两种:常驻属性和非常驻属性，常驻属性直接保存在MFT中，像文件名和相关时间信息(例如创建时间、修改时间等)永远属于常驻属性，非常驻属性则保存在MFT之外，但会使用一种复杂的索引方式来进行指示。如果文件或文件夹小于1500字节(其实我们的电脑中有相当多这样大小的文件或文件夹)，那么它们的所有属性，包括内容都会常驻在MFT中，而MFT是Windows一启动就会载入到内存中的，这样当你查看这些文件或文件夹时，其实它们的内容早已在缓存中了，自然大大提高了文件和文件夹的访问速度。

NTFS   20110524103722.675442+480  1.txt
FAT32 20110524103651.520000+***  1.txt
480包含了时区，表示相对于UTC的时差分钟数，中国是第八时区，相差480分钟

fastslz

NTFS 维基百科写的更全面一些
NTFS可以精确到100000毫秒以内（其实没那么精确）
+480取决于文件创建时系统当前设置的时区，而当前时区可以是动态的，如果这个文件拿到不同时区的电脑上，加减480值来获取相应当前系统时区的文件创建时间

qzwqzw

54# fastslz
NTFS可以精确到100000毫秒以内
可能是描述性错误
NTFS的创建时间可以精确到0.000001毫秒

wmic的结果说明不了太多的问题
只能说明ntfs的文件是成批的flush的
而且wmic的CreationDate还出现了错误
在删除文件后重新创建该文件
该文件的CreationDate显示的还是上一次创建时间
测试代码如下：

@echo off
for /l %%i in (1,1,30) do echo.A>%%i.xxx
Wmic Datafile Where "Extension='xxx' and Drive='d:' and Path='\\Test\\temp\\'" get CreationDate,name /format:htable:"sortby=CreationDate"> batfile.html
del *.xxx
for /l %%i in (1,1,30) do echo.A>%%i.xxx
Wmic Datafile Where "Extension='xxx' and Drive='d:' and Path='\\Test\\temp\\'" get CreationDate,name /format:htable:"sortby=CreationDate">> batfile.html
del *.xxx
start batfile.html
复制代码

现在已经大致有了NTFS写入文件的轮廓
文件句柄的创建与关闭肯定是顺序的
文件首先写入到缓存（可能是内存或虚拟内存）中
缓存上的文件数据块受缓存管理器管理
无论NTFS、FAT32还是exFAT都是统一的缓存管理器
NTFS卷上的文件更新时需要先更新日志文件
以便于数据文件写入失败时可以继续或者撤销
在日志文件写入物理存储之前
数据文件被缓存管理器定义为不可写NO WRITE状态
而日志文件的写入时机是受缓存管理器约束的
为了提高IO性能
缓存管理器对数据文件和日志文件的管理是多线程并发的
而受到Windows核心对CPU资源的管理策略影响
并发线程的执行顺序有一定的随机性
所以数据文件的实际写入顺序存在一定的随机性