无忧启动论坛

 找回密码
 注册
搜索
WEPE笔记本电脑手机维修小包 IT发烧友的必备工具最纯净的「微PE装机优盘」UEPON大师作品卡瑞飞系统和装机二合一超级U盘
杏雨梨云专业量产版USB-CD启动U盘,装机专用系统gho:最纯净好用系统下载站广告联系 QQ:184822951 微信:wuyouceo
楼主: 不点

最简单的 Linux 文件系统是哪个?

  [复制链接]
发表于 2019-3-6 10:52:20 | 显示全部楼层
不点 发表于 2019-3-5 14:53
不是泛泛地学习,而是提出一个问题:如何让它“简单”。比如说,一个像微软 FAT 那样简单的文件系统,又 ...

那么,假如在fat基础上添加一两个字段,用来存放权限,软链接等内容,其他基本不怎么改,这是否算一个简单的文件系统?

如果真的实现了这样一个文件系统,文件系统和linux的接口部分估计不会太简单了,因为需要满足像vfs提供inode节点等功能,可能需要不少封装和模拟才可以实现。

如果实现一个和vfs比较相近的文件系统,接口和处理代码应该会简单很多,但是文件系统的二进制结构可能就没那么简单了。

点评

exFAT 是微软的,大概只能用来学习、研究,不能企图把它改造成符合 Linux 要求的根文件系统。微软不会提供这种方便(或者说,可能性),不符合微软的利益。前面我已经说了,假如有可能那样改造的话,估计早都有人做  详情 回复 发表于 2019-3-6 12:11
回复

使用道具 举报

 楼主| 发表于 2019-3-6 12:01:57 | 显示全部楼层
exFAT Boot Sector
Offset
Size
Description
Comments
0 (0x00)
3
JumpBoot
0xEB7690
3 (0x03)
8
FileSystemName
"EXFAT>
11 (0x0B)
53
MustBeZero

64 (0x40)
8
PartitionOffset
In sectors; if 0, shall be ignored ——分区的起始扇区号(64位
72 (0x48)
8
VolumeLength
Size of exFAT volume in sectors —— 卷的扇区总数(64位
80 (0x50)
4
FatOffset
In sectors —— FAT 表的起始扇区号,应该是相对于分区起始吧
84 (0x54)
4
FatLength
In sectors. May exceed the required space in order to align the second FAT
88 (0x58)
4
ClusterHeapOffset
In sectors ——簇堆的起始扇区号,应该是相对于分区起始吧
92 (0x5C)
4
ClusterCount
2^32-11 is the maximum number of clusters could be described
96 (0x60)
4
RootDirectoryCluster
根目录的簇号
100 (0x64)
4
VolumeSerialNumber
卷序列号
104 (0x68)
2
FileSystemRevision
as MAJOR.minor, major revision is high byte, minor is low byte; currently 01.00 —— 文件系统版本号
106 (0x6A)
2
VolumeFlags * ↓
卷的标志
Offset
Size
Field
0
1
ActiveFat 0 - First FAT and Allocation Bitmap are active, 1- Second.
1
1
VolumeDirty (0-clean, 1-dirty)
2
1
MediaFailure (0 – no failures reported or they already marked as BAD clusters) 1- some read/write operations failed)
3
1
ClearToZero (no meaning)
4
12
Reserved (no meaning)
108 (0x6C)
1

BytesPerSectorShift
Power of 2. Minimum 9 (512 bytes per sector), maximum 12 (4096 bytes per sector)
109 (0x6D)
1
SectorsPerCluster Shift
Power of 2. Minimum 0 (1 sector per cluster), maximum 25 – BytesPerSectorShift, so max cluster size is 32 MB
110 (0x6E)
1

NumberOfFats
2 is for TexFAT only
111 (0x6F)
1
DriveSelect
Extended INT 13h drive number; typically 0x80 ——暗示,主板需要支持 EBIOS(LBA),而不是通常的 CHS。
112 (0x70)
1

PercentInUse
0..100 – percentage of allocated clusters rounded down to the integer 0xFF – percentage is not available
113 (0x71)
7
Reserved

120 (0x78)
390

BootCode

510 (0x1FE)
2
BootSignature
0xAA55 —— 这个启动标志固定位于 510 处,不是位于大扇区的尾部。
512 (0x200)
2^BytesPerSectorShift - 512
ExcessSpace
Not used —— 如果扇区大小超过 512 字节,多余的部分不使用。

只有分区起始扇区号和分区长度,是 64 位值,其他的量都是小值( 32 位以内的值)。这提示我们在设计一个新文件系统的时候,没必要把所有的值,都弄成 64 位。

回复

使用道具 举报

 楼主| 发表于 2019-3-6 12:11:09 | 显示全部楼层
2013olly 发表于 2019-3-6 10:52
那么,假如在fat基础上添加一两个字段,用来存放权限,软链接等内容,其他基本不怎么改,这是否算一个简 ...


exFAT 是微软的,大概只能用来学习、研究,不能企图把它改造成符合 Linux 要求的根文件系统。微软不会提供这种方便(或者说,可能性),因为那不符合微软的利益。前面我已经说了,假如有可能那样改造的话,估计早都有人做了。
回复

使用道具 举报

 楼主| 发表于 2019-3-6 14:34:31 | 显示全部楼层
exFAT - Extended Boot Sector
Offset
Size
Description
Comments
0 (0x00)
2^BytesPerSectorShift - 4
ExtendedBootCode

2^BytesPerSectorShift - 4
4
ExtendedBootSignature
0xAA550000
Whole sector is used for boot code except last 4 bytes used for signature in each sector.If Extended Boot Sector is not used, it should be filled with 0x00.Extended signature must be preserved.

对于大扇区来说,这次是使用整个扇区,而不是只有开头的 512 字节。而且,扩展引导标志是在整个扇区的尾部,而不是只在 512 字节之前。猜测这可能是因为,当 boot sector 接管控制后,已经知道了扇区大小,因此,扩展引导代码部分就可以使用整个的大扇区了。

回复

使用道具 举报

 楼主| 发表于 2019-3-6 17:30:56 | 显示全部楼层
exFAT - File Allocation Table (FAT)      

File Allocation Table (FAT) may contain 1 or 2 FATs, as defined in NumberOfFats field. ActiveFat field in VolumeFlags in the Main Boot Sector determines which FAT is active.

The first cluster is cluster 2, as in FAT32. Each FatEntry represents one cluster.

In exFAT, FAT is not used for tracking an allocation; an Allocation Bitmap is used for this purpose. FAT is only used for keeping chains of clusters of fragmented files. If a file is not fragmented, FAT table does not need to be updated. A Stream Extensions Directory Entry should be consulted to determine if the FAT chain is valid or not. If FAT chain is not valid, it does not need to be zeroed.

Offset
Size
Description
Comments
0 (0x00)
4
FatEntry[0]
Media type (should be 0xFFFFFFF8)
4 (0x04)
4
FatEntry[1]
Must be 0xFFFFFFFF
8 (0x08)
4
FatEntry[2]
First cluster
...
...
...
...
(ClusterCount + 1) * 4
4
FatEntry[ClusterCount + 1]
Last cluster
(ClusterCount + 2) * 4
Remainder of sector
ExcessSpace


Valid values of FAT entries:
  • 0x00000002 — ClusterCount +1 (max 0xFFFFFFF6) — next cluster in the chain
  • 0xFFFFFFF7 — bad cluster
  • 0xFFFFFFF8 — media descriptor
  • 0xFFFFFFFF — end of file (EOF mark)


Value 0x00000000 does not mean the cluster is free, it is an undefined value.
The second FAT table (presents only in TexFAT) is located immediately after the first one and has the same size.

Cluster Heap

The cluster heap is a set of clusters which hold data in exFAT. It contains:
  • Root Directory
  • Files
  • Directories
  • Bitmap Allocation Table
  • UP-Case Table


The allocation status of clusters in cluster heap is tracked by Bitmap Allocation Table which itself located inside the cluster heap.

从上述描述可以知道,exFAT 在很多方面都像 FAT32。它的 FAT 表项(簇号)都是 32 位的,所以,它不是 FAT64。它可以看成是改进型的 FAT32。



与 FAT32 不同,exFAT 的 FAT 表是专门用来服务于“文件碎片”的。FAT32 的文件分配表还用于跟踪空间的分配情况。在 exFAT 中,开辟了新的 “职能部门”—— Bitmap Allocation Table ——用于跟踪空间分配情况。文件无碎片时,可以不更新对应的 FAT 表项。这意味着,当文件无碎片时,FAT 表里面的原有记录,可能是错的,不能反映真实的分配情况。


我觉得还是更新了好。一个连续的文件,更新一下 FAT 表,也不会造成多大的性能损失。好处是确保 FAT 表能够反映真实分配情况。这样,第三方工具恢复误删的文件,成功的可能性就大一些。 Bitmap Allocation Table 只对提升性能有用。一个精简的文件系统,不需要 Bitmap Allocation Table,就是说,原先的 FAT32 的那种处理,就算是可以了。


再一个细节的讨论,就是有关“0xFFFFFFFF — end of file (EOF mark)” 的。这是文件的最后一簇,它没有后续的簇号,因此,使用了 0xFFFFFFFF 来当作结束的标志。但是,这个结束标志带来的信息却仅仅是 “结束”而已,没能提供更加有用的信息。在设计某个新的文件系统时,如果用该文件的起始簇号来取代此处的 0xFFFFFFFF,则能够提供有价值的信息。就是说,当遇到起始簇号时,就认为到达了文件的结尾,这完全能够清晰地表明文件“结束”了。这样做的好处是,第三方恢复工具能够从一个 chain 的随便某个簇号开始,顺藤摸瓜,最终能找到起始簇号。如果是以 0xFFFFFFFF 结束,则无法方便快捷地找到起始簇号(需要遍历整个 FAT 表,才能找到起始簇号)。



回复

使用道具 举报

发表于 2019-3-6 22:04:39 | 显示全部楼层
slore 发表于 2019-3-5 22:39
如果作为文件系统学习的话,越小越好。

Menuet OS 1.4MB,不过这货不是Linux。Linux体系的话4MB?

当年玩过一个小系统,好像是1.4M,,还能驱动网卡,内置几个小游戏。不过忘记名字了。
回复

使用道具 举报

 楼主| 发表于 2019-3-7 06:55:23 | 显示全部楼层
exFAT — Directory Structure


exFAT uses tree structure to describe relationship between files and directories. The root of the directory tree is defined by directory located at RootDirectoryCluster. Subdirectories are single-linked to there parents. There is no special (.) and (..) directories pointing to itself and to parent like in FAT16/FAT32.
Each directory consists of a series of directory entries. Directory entries are classified as critical/benign and primary/secondary as follows:
  • Primary Directory Entries

    • Critical Primary Entries
    • Benign Primary Entries

  • Secondary Directory Entries

    • Critical Primary Entries
    • Benign Primary Entries

Critical entries are required while benign entries are optional. Primary directory entries correspond to the entries in file system and describe main characteristics. Secondary directory entries extend the metadata associated with a primary directory entry end follow it.
A group of primary/secondary entries make up a directory entry set describing a file or directory. The first directory entry in the set is a primary directory entry. All subsequent entries, if any, must be secondary directory entries.
Each directory entry derives from Generica Directory Entry template. Size of directory entry is 32 bytes.
Offset
Size
Description
Comments
0 (0x00)
1
EntryType ↓

Bits
Size
Description
Comments
0-4
5
Code
5
1
Importance
0 — Critical entry, 1 — Benign entry
6
1
Category
0 — Primary entry, 1 — Secondary entry
7
1
In use status
0 – Not in use, 1 – In use
1 (0x01)
19
CustomDefined

20 (0x14)
4
FirstCluster
0 – no cluster allocation 2..ClusterCount+1 – cluster index
24 (0x18)
8
DataLength
In bytes
EntryType can have the following values:
  • 0x00 — End Of Directory marker. All other fields in directory entry are invalid. All subsequent directory entries are also End Of Directory markers
  • 0x01-0x7F (InUse = 0). All other fields in this entry are not defined
  • 0x81-0xFF (InUse = 1). Regular record with all fields defined.

Generic Primary Directory Entry Template

Offset
Size
Description
Comments
0 (0x00)
1
EntryType ↓

1 (0x01)
1
SecondaryCount
Number of secondary entries which immediately follow this primary entry and together comprise a directory entry set. Valid value is 0..255
2 (0x02)
2
SetChecksum
Checksum of all directory entries in the given set excluding this field. See EntrySetCheckSum().
4 (0x04)
2
GeneralPrimaryFlags

Bits
Size
Description
Comments
0
1
AllocationPossible
0-not possible (FirstCluster and DataLength undefined), 1-possible
1
1
NoFatChain
0-FAT cluster chain is valid 1-FAT cluster chain is not used (contiguous data)
2
14
CustomDefined

6 (0x06)
14
CustomDefined

20 (0x14)
4
FirstCluster

24 (0x18)
8
DataLength

All critical primary directory entries are located in root directory (except file directory entries). Benign primary directory enries are optional. If one benign primary entry is not recognized, all directory entry set is ignored.

Generic Secondary Directory Entry Template

Offset
Size
Description
Comments
0 (0x00)
1
EntryType ↓

1 (0x01)
1
GeneralSecondaryFlags

Bits
Size
Description
Comments
0
1
AllocationPossible

1
1
NoFatChain

2
14
CustomDefined

2 (0x02)
18
CustomDefined

20 (0x014)
4
FirstCluster

24 (0x018)
8
DataLength


Defined Directory Entries

EntryType
Primary
Critical
Code
Directory Entry
0x81
·
·
1
Allocation Bitmap
0x82
·
·
2
Up-case Table
0x83
·
·
3
Volume Label
0x85
·

5
File
0xA0
·
·
0
Volume GUID
0xA1
·

1
TexFAT Padding
0xA2
·

2
Windows CE Access Control Table
0xC0

·
0
Stream Extension
0xC1

·
1
File Name


可以看到,簇号占用 32 位,文件大小占用 64 位。我们留意,exFAT 对于 FAT32 的改进,最要紧的,也就在于将文件大小从 32 位扩展为 64 位。

回复

使用道具 举报

 楼主| 发表于 2019-3-7 08:44:40 | 显示全部楼层
exFAT — File Directory Entry

File directory entry describes files and directories. It is a primary critical directory entry and must be immediately followed by 1 Stream Extension directory entry and from 1 to 17 File Name directory entries . Those 3-19 directory entries comprise a directory entry set describing a single file or a directory.
Offset
Size
Description
Comments
0 (0x00)
1
EntryType
0x85
1 (0x01)
1
SecondaryCount
Must be from 2 to 18
2 (0x02)
2
SetChecksum

4 (0x04)
2
FileAttributes

Bits
Size
Attribute
Comments
0
1
ReadOnly

1
1
Hidden

2
1
System

3
1
Reserved1
这里保留了 1 个 bit
4
1
Directory

5
1
Archive

6
10
Reserved2
这里保留了 10 个 bit
6 (0x06)
2
Reserved1
这里保留了 2 个字节
8 (0x08)
4
CreateTimestamp

12 (0x0C)
4
LastModifiedTimestamp

16 (0x10)
4
LastAccessedTimestamp

20 (0x14)
1
Create10msIncrement
0..199
21 (0x15)
1
LastModified10msIncrement
0..199
22 (0x16)
1
CreateTimezoneOffset
Offset from UTC in 15 min increments
23 (0x17)
1
LastModifiedTimezoneOffset
Offset from UTC in 15 min increments
24 (0x18)
1
LastAccessedTimezoneOffset
Offset from UTC in 15 min increments
25 (0x19)
7
Reserved2
这里保留了 7 个字节


File Name Directory Entry
     
Offset
Size
Description
Comments
0 (0x00)
1
EntryType
0xC1
1 (0x01)
1
GeneralSecondaryFlags

Bits
Size
Attribute
Comments
0
1
AllocationPossible
Must be 0
1
1
NoFatChain
Must be 0
2
14
CustomDefined

2 (0x02)
30
FileName

File Name directory entries must immediately follow the Steam Extension directory entry in the number of NameLength/15 rounded up.
The maximum number of File Name entries is 17, each can hold up to 15 Unicode characters and the maximum file name length is 255. Unused portion of FileName field must be set to 0x0000.

Invalid File Name Characters


Character Code
Character
Description
0x0000 – 0x001F

Control codes
0x0022
"
Quotation mark
0x002A
*
Asterisk
0x002F
/
Forward slash
0x003A
:
Colon
0x003C
<
Less than
0x003E
>
Greater than
0x003F
?
Question mark
0x005C
\
Back slash
0x007C
|
Vertical bar

可以看到,exFAT 的目录项中,确实有一些保留位和保留字节。这为支持 Linux 权限设置,提供了可能性。但是,这些保留的字段,微软将来也有可能使用。如果真的要着手进行改造的话,就得猜测微软到底将来会怎么使用这些字段,以及可能的冲突会有多大,严重不严重。即便能够改造,也不一定值得去改造。exFAT 沿用了微软的很多习惯,这些习惯,与 Linux 有冲突。比如,文件名不区分大小写,这反而是个问题,因为你还得花费精力去比较文件名,让大小写一样的文件名视为相同的,这就增加了负担,不如像 Linux 目前这样 “区分大小写”,更简单、方便。再比如,一个长文件名,在 exFAT 的目录项中分为好多碎片,这也不如 Linux 的 ext2 目录项中的文件名是连续的一个字符串,来得更合理。


又比如,微软习惯于在目录项中存储 unicode 文件名(UTF-16 格式),这带来的好处不一定有多大。我认为(如果设计)一个(新的) Linux 的文件系统,应该在目录项中存储 UTF-8 格式的文件名。分析如下:(一)UTF-16 和 UTF-8 都是变长的。UTF-16 的好处是,在常用文字 65536 个字符(BMP)以内,统一都是 2 字节。但在 BMP 以外,需要 4 字节。而且,UTF-16 最大只能处理 unicode 的码点 0x10FFFF,目前虽然够用,但将来 unicode 字符集完善以后,就处理不了了。UTF-8 的好处是,可以处理全部 unicode 码点,没有死角。UTF-8 的缺点是,在 65536 个字符以内,UTF-8 是变长的,可能在 1 到 3 个字节之间变动。汉字是 3 个字节。当然了,谁如果不是吃饱了撑的,也不会在文件名中采用 BMP 以外的冷僻字符。因此,在变长问题上,UTF-16 稍稍占优。(二)UTF-16 在普通的终端使用上,还是不行的,需要转换。而 UTF-8 几乎在 Linux 下取得事实工业标准的地位了。使用时不需要转换。比如,ls 命令列出的文件名,与磁盘上保存的文件名是一样的字符串,都是 UTF-8 格式。(三)UTF-16 和 UTF-32 都存在 “字节序” (大小端)问题,UTF-8 不存在这样的问题。(四)UTF-16 在 65536 个字符(BMP)以内,节约了汉字的空间占用(只占 2 字节),比 UTF-8 的 3 字节,少占用一个字节。但它浪费了英文字符一个字节:UTF-8 只需一个字节,UTF-16 需要 2 个字节(UTF-32 需要 4 个字节)。然而,英文字符文件名是更频繁使用的文件名,尤其是对于 Linux 用户来说,更是这样,因此,这种浪费就有点大了。当然了,在文件名方面,浪费一些字节,也不是很要紧的。一个长篇小说的浪费,才算是浪费。综合以上几条,在 Linux 的文件系统内部直接采用 UTF-8 文件名,相比于 UTF-16 和 UTF-32,优势更大一些。



exFAT 的文件名和目录项信息集中放在了一起;Linux 的 ext2 中的目录项只记录文件名和 inode 的对应关系,而由另外的 inode 结构来记录文件的信息。我认为,Linux 的 ext2 的做法更好一点。但是,Linux 的 ext2 中,对磁盘块多级寻址,还是复杂了。微软的 FAT 和 exFAT 中都是用单一的簇号链(链接表)来寻址,这在逻辑上是非常简单的。



回复

使用道具 举报

 楼主| 发表于 2019-3-7 10:33:34 | 显示全部楼层
本帖最后由 不点 于 2019-3-30 10:27 编辑

Linux 文件系统中的一个特性——硬链接——好像是微软不曾使用的(更正:NTFS 好像也支持硬链接)。当然了,硬链接究竟能有多大用处的问题,也值得讨论。不过,现在先不讨论这个问题。贴一篇文章,了解这方面的知识。

理解 Linux 的硬链接与软链接
https://www.ibm.com/developerworks/cn/linux/l-cn-hardandsymb-links/

摘录如下:

由于硬链接是有着相同 inode 号仅文件名不同的文件,因此硬链接存在以下几点特性:

    文件有相同的 inode 及 data block;
    只能对已存在的文件进行创建;
    不能交叉文件系统进行硬链接的创建;
    不能对目录进行创建,只可对文件创建;
    删除一个硬链接文件并不影响其他有相同 inode 号的文件。

软链接的创建与使用没有类似硬链接的诸多限制:

    软链接有自己的文件属性及权限等;
    可对不存在的文件或目录创建软链接;
    软链接可交叉文件系统;
    软链接可对文件或目录创建;
    创建软链接时,链接计数 i_nlink 不会增加;
    删除软链接并不影响被指向的文件,但若被指向的原文件被删除,则相关软连接被称为死链接(即 dangling link,若被指向路径文件被重新创建,死链接可恢复为正常的软链接)。


上述文章还提到了“文件太多导致 inode 被用光(无法创建新文件了),但文件系统的空闲空间却还有很多”的情况。这说明,固定 inode 数目的文件系统设计,也有它不合理的一面。微软的文件系统不存在这个问题(更正:支持硬链接的 NTFS 是否存在这个问题,也未可知)。

回复

使用道具 举报

 楼主| 发表于 2019-3-8 11:46:07 | 显示全部楼层
ext4 — Linear (Classic) Directories


By default, each directory lists its entries in an “almost-linear”array. I write “almost” because it’s not a linear array in the memorysense because directory entries are not split across filesystem blocks.Therefore, it is more accurate to say that a directory is a series ofdata blocks and that each block contains a linear array of directoryentries. The end of each per-block array is signified by reaching theend of the block; the last entry in the block has a record length thattakes it all the way to the end of the block. The end of the entiredirectory is of course signified by reaching the end of the file. Unuseddirectory entries are signified by inode = 0. By default the filesystemuses struct ext4_dir_entry_2 for directory entries unless the“filetype” feature flag is not set, in which case it usesstruct ext4_dir_entry.
The original directory entry format is struct ext4_dir_entry, whichis at most 263 bytes long, though on disk you’ll need to referencedirent.rec_len to know for sure.

OffsetSizeNameDescription
0x0__le32inodeNumber of the inode that this directory entry points to.
0x4__le16rec_lenLength of this directory entry. Must be a multiple of 4.
0x6__le16name_lenLength of the file name.
0x8charname[EXT4_NAME_LEN]File name.

Since file names cannot be longer than 255 bytes, the new directoryentry format shortens the rec_len field and uses the space for a filetype flag, probably to avoid having to load every inode during directorytree traversal. This format is ext4_dir_entry_2, which is at most263 bytes long, though on disk you’ll need to referencedirent.rec_len to know for sure.

OffsetSizeNameDescription
0x0__le32inodeNumber of the inode that this directory entry points to.
0x4__le16rec_lenLength of this directory entry.
0x6__u8name_lenLength of the file name.
0x7__u8file_typeFile type code, see ftype table below.
0x8charname[EXT4_NAME_LEN]File name.

The directory file type is one of the following values:

ValueDescription
0x0Unknown.
0x1Regular file.
0x2Directory.
0x3Character device file.
0x4Block device file.
0x5FIFO.
0x6Socket.
0x7Symbolic link.

ext4 的上述目录结构,非常简单,它只把文件名同 inode 号码对应起来,就完事。然而,为了加快目录项的定位,后来还发明了 Hash Tree Directories,非常复杂。它为了与 ext2 兼容,可能没法对上述目录结构进行大的修改,所以,只能另外设计一个结构,而不是直接修改现有结构。假如我们要设计一个新的文件系统,就不必考虑与 ext2 的兼容问题了,因此,我们可以直接改进目录表的结构。比如说,改成这样:


OffsetSizeNameDescription
0x0__le32inodeNumber of the inode that this directory entry points to.
0x4__le16rec_lenLength of this directory entry.
0x6__u8name_lenLength of the file name.
0x7__u8file_typeFile type code.
0x8__le32hashFile name hash.
0xCcharname[EXT4_NAME_LEN]File name.

同一目录下的文件名,使用的频度是不同的。可以再增加一个字段,用来表示访问次数。访问次数多的,调整到该目录的第一磁盘块(或者前 4 个磁盘块),让它更容易被找到。


另外,目录结构也不一定从一开始就是目录项的记录。可以在开头有一个说明性的 super 区域,记录着该目录的一些变量或信息。比如,有个变量表示本信息域的长度,指示实际的目录项从哪里开始。另外有两个变量分别记录该目录下最大的访问次数和最小的访问次数。当最小的访问次数已经达到最大访问次数的一半时,应该把本目录下所有文件的访问次数都减去这个最小值。当最大值将要溢出时,把本目录下所有文件的访问次数都除以 2。



对于很久(比如 30 天)都没有修改的文件(看修改时间就可知道这一点),操作系统应该在空闲时,对其进行整理碎块,让它变成连续的。inode 结构中应该有个字段,表示文件是否连续(就像微软所做的那样)。

回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

小黑屋|手机版|Archiver|捐助支持|无忧启动 ( 闽ICP备05002490号-1 )

闽公网安备 35020302032614号

GMT+8, 2019-6-21 00:07

Powered by Discuz! X3.3

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表