Chinaunix首页 | 论坛 | 博客
  • 博客访问: 86410
  • 博文数量: 42
  • 博客积分: 2630
  • 博客等级: 少校
  • 技术积分: 415
  • 用 户 组: 普通用户
  • 注册时间: 2008-12-23 11:05
文章分类
文章存档

2011年(1)

2010年(41)

我的朋友

分类: LINUX

2010-09-15 12:23:08

硬盘的物理组成:
硬盘是由硬盘片组成的,分为单片盘与多片盘。
硬盘上有磁头(head)在硬盘片上读写,磁头固定在机械手臂上,机械手臂上有多个磁头,可以进行读取数据。
硬盘上又被划分成多个磁道(track),所有硬盘片上相同半径的那个磁道就组成了柱面(cylinder)。磁道又被划分成扇区。扇区就是硬盘上最小的存储单位。通常一个扇区的大小约为512字节。
整个磁盘的容量简单的公式为:柱面*磁头*扇区*512字节。
这里有不理解的地方,我实际打开一个硬盘发现里面只有一个磁头,所以这个硬盘的大小应该为
柱面*1*扇区*512字节,但我用命令#fdisk -l 看到的却是下面这样的信息:
[root@php-test ~]# fdisk -l
Disk /dev/hda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start       End      Blocks   Id  System
/dev/hda1   *           1          13      104391   83  Linux
/dev/hda2              14         274     2096482+  82  Linux swap / Solaris
/dev/hda3             275        9729    75947287+  83  Linux
从上面的信息我们看到有255个磁头,每个轨道上有63个扇区,总共有9729个磁柱,每个磁道的扇区为:255*63=16065 个, 每个磁柱的大小容量为16065*512=8225280 bytes, 整个硬盘的大小就为8225280*9729=80026361856 bytes.
为什么这里看到的是255个磁头。实际拆开看到的却是1个磁头呢?莫非是我的肉眼不行。
 
分区
MBR是在一块硬盘的第0轨上,这也是计算机启动之后要去使用硬盘时必须读取的第一个区域。这个区域记录了硬盘里的所有分区信息,以及启动时引导程序所在的位置。MBR最多可记忆4个分区的信息。也就是记录每个分区的起始柱面与结束柱面。接着就是将分区格式化为操作系统能够识别的文件系统。
硬盘的最小存储单位是扇区,而数据的最小存储单位是块,也就是说在格式化时所指定的最小存储单位---块,这个块的大小为扇区的2 的N次方的倍数。此时磁头一次可以读取一块,大大提高了文件的读取效率。
在考虑块的规划时,考虑以下问题:
1.文件读取的效率。(块太小文件读取效率差点)
2.硬盘空间的使用率。(块太大可能造成硬盘空间的浪费)
 在分区后,每个分区就是一个文件系统,而每个文件系统开始的位置的那个块就称为超级块
(superblock)。超级块的作用就是存储文件系统的大小,空的和填满的块,以及它们各自的总数和其它诸如此类的信息。
 
inode
标准的ext2文件系统中,每个文件的内容分为两个部分来存储,一个是文件的属性,另一个则是文件的内容。
ext2用inode存储文件的属性,用块来存储文件的内容。要将一个分区格式化为ext2的文件系统时,必须指定 inode 与块的大小才行,也就说一定会有 inode 表与块区域这两个区域。
inode 记录的是文件的属性以及文件内容放置在哪个块内,也就是指针功能。
  • 该文件的拥有者和用户组
  • 该文件的权限(读,写,执行)
  • 该文件的类型
  • 该文件的(ctime,atime,mtime)
  • 该文件的大小
  • 定义文件属性的标志
  • 该文件的指针
Linux系统是如何对文件的进行读取的:
目录:
当建立一个目录时,ext2会给该目录分配一个 inode 与至少一个块。其中 inode 记录该目录的相关属性,并指向分配到的那个块,这个块记录在这个目录下的相关文件和目录的关联性。
文件:
当建立一个文件时,ext2会给该文件分配至少一个inode及相对该文件大小的块数量。例如一个块的大小为4KB,当要建立一个100KB的文件时,Linux将分配一个inode 与25个块来存储该文件。
 
问题:
    当文件增大时,系统会修改这个块的数量?这个块数量记录在哪里?
    在读取文件时,在磁头读完一块后是如何获取到下一个块的位置?
 
inode本身并不记录文件名,而是记录文件的相关属性,文件名记录在目录所属的块区域。
文件的相关连接会记录在目录的块数据区域。
所以要读取一个文件的内容时,Linux会先由根目录目录 / 获取该文件的上层目录所在的inode,再由该目录所记录的文件的关联性(在该目录所属的块区域)获取该文件的inode,最后通过inode 内提供的块指针来获取最终文件的内容。
所以目录的最大功能就是提供文件的关联性,在关联性中,最主要的就是文件名与inode的对应数据。
  • ext2与ext3在格式化分区后就已经设置好固定的inode数与块数目了
  • ext2允许的块大小为1024,2048,4096字节。
  • 一个分区所能容许的最大文件数与inode的数量有关,因为一个文件至少要占用一个inode。
  • 如果目录下面的文件数目太多,导致一个块无法容纳所有的关联数据时,Linux会给予该目录多个块,来继续记录关联数据。
  • 通常inode数量设置为:分区的容量/一个inode预计想要控制的容量。
  • 一个inode占用128字节的空间。
  • 因为一个inode 只能记录一个文件属性,所以inode数量比块多是没有意义的。
  • 块越小,inode数量越多,则可利用的空间越多,但文件写入的效率较差。
  • 块越大,inode数量越少,大文件写入的效率较好,但可能浪费的硬盘空间较多。
  • 对于单一文件,若块大小=1024,最大容量为16GB,若块大小为4096,则容量为2TB。
  • 对于整个分区,若块大小=1024,则容量为2TB,若块大小为4096,则容量为32TB。
  • 文件是不可能存储在连续的块上的,如果文件写的很分散,就会有文件碎片产生。ext2在inode处已经记录了该文件的编号(block number),可以一次性读取数据,但文件太零碎,还是会发生读取效率低的问题。
  • 分区不是越大越好,太大就有可能造成读取数据效率低下(数据存储不连续时,机械手臂来回移动)。
问题:
     1.文件最大容量是如何算出来的?与inode有关系吗?
     2.当文件不连续存储时,系统是如何知道下一个块的位置的呢?
     3.分区的最大容量是如何算出来的?
 
当建立ext2的文件系统时,会按照分区的大小,确定数个块组,每个块组都将拥有:
  1. 超级块(superblock):记录内容有:
    • 块与inode的总量;
    • 未使用与已使用的inode,块数量;
    • 一个块与一个inode的大小;
    • 文件系统的载入时间,最近一次写入数据的时间,最近一次检验磁盘(fsck)的时间等文件系统的相关信息;
    • 有效位(valid bit)数值,若此文件系统已经载入,则有效位为0,若未被载入,则有效位为1。
  2. Group Description(组描述):记录此块由何处开始记录。
  3. Block bitmap(块位图):此处记录块是否已使用。
  4. Inode bitmap(inode位图):此处记录inode是否已使用。
  5. Inode table(inode表):为每个inode的数据存放区。
  6. Data Blocks(数据块):为每个块的数据存放区。
有的块组可能不包括超级块,有的块组只是超级块的一个备份。
查看超级块及块组信息用 dumpe2fs 命令查看。
 
下面是从网上找的一个关于如何修复superblock 的例子。
先是模拟把superblock 损坏,随便建一个aa的文件。
#dd if=/tmp/aa of=/dev/hda5 bs=1 count=100 seek=1024
[root@dhcp-0-142 ~]# mount /dev/sdb1 /mnt/sdb1
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
[root@dhcp-0-142 ~]# dumpe2fs /dev/sdb1
dumpe2fs 1.39 (29-May-2006)
Filesystem volume name:
Last mounted on:
Filesystem UUID: c3800df3-5c34-4b53-8144-94029b5736d8
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal resize_inode dir_index filetype
sparse_super
Default mount options: (none)
Filesystem state: clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 0
Block count: 0
Reserved block count: 0
Free blocks: 20926971
Free inodes: 4705752
First block: 1
Block size: 1024
Fragment size: 1024
Reserved GDT blocks: 256
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 2008
Inode blocks per group: 251
Filesystem created: Tue Oct 7 19:18:08 2008
Last mount time: n/a
Last write time: Tue Oct 7 19:29:39 2008
Mount count: 0
Maximum mount count: 20
Last checked: Tue Oct 7 19:18:08 2008
Check interval: 15552000 (6 months)
Next check after: Sun Apr 5 19:18:08 2009
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 7f7e1c41-5cae-4f23-9873-877991751ccb
Journal backup: inode blocks
dumpe2fs: Illegal inode number while reading journal inode
[root@dhcp-0-142 ~]#
根据Blocks per group: 8192的信息,我定位了第一个备份superblock的位置为8193。也可以在后面组块的信息中(backup superblock at 8193)知道备份superblock的位置。
所以我做如下操作:
[root@dhcp-0-142 ~]# fsck -b 8193 /dev/sdb1
fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
/dev/sdb1 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb1: 11/26104 files (9.1% non-contiguous), 8966/104388 blocks
[root@dhcp-0-142 ~]# mount /dev/sdb1 /mnt/sdb1
[root@dhcp-0-142 ~]# ls /mnt/sdb1
lost+found
[root@dhcp-0-142 ~]#
superblock已经修复,文件系统挂载正常。
之所以这么做,是有依据的。
ext2/3文件系统在创建文件系统的时候会创建若干个superblock的备份存放于特定位置。
[root@dhcp-0-142 ~]# dumpe2fs /dev/sdb1 | grep --before-context=1 superblock
dumpe2fs 1.39 (29-May-2006)
Group 0: (Blocks 1-8192)
Primary superblock at 1, Group descriptors at 2-2
--
Group 1: (Blocks 8193-16384)
Backup superblock at 8193, Group descriptors at 8194-8194
--
Group 3: (Blocks 24577-32768)
Backup superblock at 24577, Group descriptors at 24578-24578
--
Group 5: (Blocks 40961-49152)
Backup superblock at 40961, Group descriptors at 40962-40962
--
Group 7: (Blocks 57345-65536)
Backup superblock at 57345, Group descriptors at 57346-57346
--
Group 9: (Blocks 73729-81920)
Backup superblock at 73729, Group descriptors at 73730-73730
[root@dhcp-0-142 ~]#
从上面操作可以看出,在第1、3、4、7、9这几个Block Group上存放有superblock备份。
什么是Block Group?ext2/3文件系统为了提高磁盘寻道效率,把inode table等信息按照
Inodes per group分成若干组存放,而没有全部放在一起。
此图摘自:
Inodes per group信息相见命令:
[root@dhcp-0-142 ~]# dumpe2fs /dev/sdb1 | grep 'Inodes per group'
dumpe2fs 1.39 (29-May-2006)
Inodes per group: 2008
[root@dhcp-0-142 ~]#
有些文件系统superblock损坏的很厉害。连dumpe2fs和tune2fs都看不到
信息。
[root@dhcp-0-175 ~]# dd if=/dev/zero of=/dev/sdb1 bs=1 count=1024 seek=1024
1024+0 records in
1024+0 records out
1024 bytes (1.0 kB) copied, 0.0228272 seconds, 44.9 kB/s
[root@dhcp-0-175 ~]# dumpe2fs /dev/sdb1
dumpe2fs 1.39 (29-May-2006)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb1
Couldn't find valid filesystem superblock.
[root@dhcp-0-175 ~]# tune2fs -l /dev/sdb1
tune2fs 1.39 (29-May-2006)
tune2fs: Bad magic number in super-block while trying to open /dev/sdb1
Couldn't find valid filesystem superblock.
[root@dhcp-0-175 ~]#
这时候我们根本无法从dumpe2fs和tune2fs看到Backup superblock的位置。
我们可以尝试从superblock的结构来猜测superblock的位置(superblock结构见上图)。
我们从superblock结构可以知道,卷标volume name存放于superblock中。所以如果文件系
统有设置卷标,那么我们可以尝试从卷标来定位superblock。
我们用hexdump把文件系统dump出来:
[root@dhcp-0-175 ~]# hexdump -C /dev/sdb1 > /var/sdb1.hexdump
[root@dhcp-0-175 ~]#
我们已知 /dev/sdb1的卷标是sdb1(如果不知道卷标或者没有设置卷标,那么我就没办法了)。
我们搜索sdb1,搜到结果如下:
我们猜测这里就是备份superblock的位置。
卷标起始位置是0x18000078。由于superblock结构里volume name位于0x78的位置,所以
我们可以猜测备份superblock的起始位置是0x18000078 – 0x78 = 0x18000000。
由于blocksize位于superblock的[0x18, 0x22)的位置,这里的值是0x0002,得出blocksize是
0x0400 x ( 0x00020x0002 ) = 0x1000 = 4096
( [0x18, 0x22) 处值n和blocksize的关系是 blocksize = 0x0400 x 0x0002n,此公式感谢得新倾
情赞助)
而备份superblock的偏移量为offset / blocksize,即0x18000000 / 0x1000 = 0x00018000 =
98304。
因此我们执行:
[root@dhcp-0-175 ~]# fsck.ext3 -b 98304 /dev/sdb1
e2fsck 1.39 (29-May-2006)
sdb1 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
sdb1: ***** FILE SYSTEM WAS MODIFIED *****
sdb1: 11/123648 files (9.1% non-contiguous), 8298/246991 blocks
[root@dhcp-0-175 ~]#
这样文件系统就有给修复的可能性了。
测试一下:
[root@dhcp-0-175 ~]# dumpe2fs /dev/sdb1
dumpe2fs 1.39 (29-May-2006)
Filesystem volume name: sdb1
Last mounted on:
Filesystem UUID: 0293bd85-b911-43bf-853e-6588b3eaaf39
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal resize_inode dir_index filetype
sparse_super large_file
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 123648
Block count: 246991
Reserved block count: 12349
Free blocks: 238693
Free inodes: 123637
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 60
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 15456
Inode blocks per group: 483
Filesystem created: Wed Oct 8 12:49:09 2008
Last mount time: n/a
Last write time: Wed Oct 8 12:52:10 2008
Mount count: 0
Maximum mount count: 28
Last checked: Wed Oct 8 12:52:10 2008
Check interval: 15552000 (6 months)
Next check after: Mon Apr 6 12:52:10 2009
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 2efa124c-dde6-4046-9181-a05b7e6d182a
Journal backup: inode blocks
Journal size: 16M
Group 0: (Blocks 0-32767)
Primary superblock at 0, Group descriptors at 1-1
Reserved GDT blocks at 2-61
Block bitmap at 62 (+62), Inode bitmap at 63 (+63)
Inode table at 64-546 (+64)
28113 free blocks, 15445 free inodes, 2 directories
Free blocks: 4655-32767
Free inodes: 12-15456
Group 1: (Blocks 32768-65535)
Backup superblock at 32768, Group descriptors at 32769-32769
Reserved GDT blocks at 32770-32829
Block bitmap at 32830 (+62), Inode bitmap at 32831 (+63)
Inode table at 32832-33314 (+64)
32221 free blocks, 15456 free inodes, 0 directories
Free blocks: 33315-65535
Free inodes: 15457-30912
Group 2: (Blocks 65536-98303)
Block bitmap at 65536 (+0), Inode bitmap at 65537 (+1)
Inode table at 65538-66020 (+2)
32283 free blocks, 15456 free inodes, 0 directories
Free blocks: 66021-98303
Free inodes: 30913-46368
Group 3: (Blocks 98304-131071)
Backup superblock at 98304, Group descriptors at 98305-98305
Reserved GDT blocks at 98306-98365
Block bitmap at 98366 (+62), Inode bitmap at 98367 (+63)
Inode table at 98368-98850 (+64)
32221 free blocks, 15456 free inodes, 0 directories
Free blocks: 98851-131071
Free inodes: 46369-61824
Group 4: (Blocks 131072-163839)
Block bitmap at 131072 (+0), Inode bitmap at 131073 (+1)
Inode table at 131074-131556 (+2)
32283 free blocks, 15456 free inodes, 0 directories
Free blocks: 131557-163839
Free inodes: 61825-77280
Group 5: (Blocks 163840-196607)
Backup superblock at 163840, Group descriptors at 163841-163841
Reserved GDT blocks at 163842-163901
Block bitmap at 163902 (+62), Inode bitmap at 163903 (+63)
Inode table at 163904-164386 (+64)
32221 free blocks, 15456 free inodes, 0 directories
Free blocks: 164387-196607
Free inodes: 77281-92736
Group 6: (Blocks 196608-229375)
Block bitmap at 196608 (+0), Inode bitmap at 196609 (+1)
Inode table at 196610-197092 (+2)
32283 free blocks, 15456 free inodes, 0 directories
Free blocks: 197093-229375
Free inodes: 92737-108192
Group 7: (Blocks 229376-246990)
Backup superblock at 229376, Group descriptors at 229377-229377
Reserved GDT blocks at 229378-229437
Block bitmap at 229438 (+62), Inode bitmap at 229439 (+63)
Inode table at 229440-229922 (+64)
17068 free blocks, 15456 free inodes, 0 directories
Free blocks: 229923-246990
Free inodes: 108193-123648
[root@dhcp-0-175 ~]# mount /dev/sdb1 /mnt
[root@dhcp-0-175 ~]# ls /mnt
lost+found
[root@dhcp-0-175 ~]#
看来我运气很好。文件系统成功修复。
其实对于这种superblock破坏很严重的文件系统,其实系统已经有了很强大的修复方案:
我们可以用mke2fs -S 来修复superblock。
mke2fs -c 还可检查是否有损坏的块。
[root@dhcp-0-175 /]# mount /dev/sdb1 /mnt/
mount: you must specify the filesystem type
[root@dhcp-0-175 /]# mount /dev/sdb1 /mnt/ -t ext3
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
[root@dhcp-0-175 /]# mke2fs -S /dev/sdb1
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
24480 inodes, 97656 blocks
4882 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
12 block groups
8192 blocks per group, 8192 fragments per group
2040 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 37 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
[root@dhcp-0-175 /]# mount /dev/sdb1 /mnt/
[root@dhcp-0-175 /]# cd /mnt
[root@dhcp-0-175 mnt]# ls
file0 file14 file20 file27 file33 file4 file46 file52 file59 file65
file71 file78 file84 file90 file97
file1 file15 file21 file28 file34 file40 file47 file53 file6 file66
file72 file79 file85 file91 file98
file10 file16 file22 file29 file35 file41 file48 file54 file60 file67
file73 file8 file86 file92 file99
file100 file17 file23 file3 file36 file42 file49 file55 file61 file68
file74 file80 file87 file93 lost+found
file11 file18 file24 file30 file37 file43 file5 file56 file62 file69
file75 file81 file88 file94
file12 file19 file25 file31 file38 file44 file50 file57 file63 file7
file76 file82 file89 file95
file13 file2 file26 file32 file39 file45 file51 file58 file64 file70
file77 file83 file9 file96
[root@dhcp-0-175 mnt]#
e2fsck也可以达到同样的效果

[root@dhcp-0-175 /]# mount /dev/sdb1 /mnt/ -t ext3
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
[root@dhcp-0-175 /]# e2fsck /dev/sdb1
e2fsck 1.39 (29-May-2006)
Couldn't find ext2 superblock, trying backup blocks...
/dev/sdb1 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (3549, counted=3547).
Fix? yes
Free blocks count wrong (88895, counted=88893).
Fix? yes
Free inodes count wrong for group #0 (2029, counted=1929).
Fix? yes
Free inodes count wrong (24469, counted=24369).
Fix? yes
/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb1: 111/24480 files (1.8% non-contiguous), 8763/97656 blocks
[root@dhcp-0-175 /]# mount /dev/sdb1 /mnt/ -t ext3
[root@dhcp-0-175 /]# ls /mnt
file0 file15 file21 file28 file34 file40 file47 file53 file6 file66
file72 file79 file85 file91 file98
file1 file16 file22 file29 file35 file41 file48 file54 file60 file67
file73 file8 file86 file92 file99
file10 file17 file23 file3 file36 file42 file49 file55 file61 file68
file74 file80 file87 file93 lost+found
file11 file18 file24 file30 file37 file43 file5 file56 file62 file69
file75 file81 file88 file94
file12 file19 file25 file31 file38 file44 file50 file57 file63 file7
file76 file82 file89 file95
file13 file2 file26 file32 file39 file45 file51 file58 file64 file70
file77 file83 file9 file96
file14 file20 file27 file33 file4 file46 file52 file59 file65 file71
file78 file84 file90 file97
 
 
常用的修改磁盘参数命令
mknod
 
e2label 用来修改磁盘的表头数据,也就是卷标。
#e2label /dev/hda5  hda5
 
tune2fs
-j: 将ext2 的文件系统转换为ext3的文件系统。
-l: 列出超级块的信息。
-L: 修改文件系统的卷标。
 
hdparm
可以开启硬盘的DMA(Direct Memory Access)模式功能。
DMA是直接内存访问这是指一种高速的数据传输操作,允许在外部设备和存储器之间直接读写数据,既不通过CPU,也不需要CPU干预。整个数据传输操作在一个称为"DMA控制器"的控制下进行的。
UDMA模式:(Ultra-DMA/33),1996年由Intdl和Quantum制定的一种数据传输方式,该方式I/O系统的突 发数据传输速度可达33MB/s,还可以降低I/O系统对CPU资源的占用率。
查看硬盘当前的DMA模式
#hdparm -i /dev/hda
DMA: mdma0 mdma1 mdma2
udma0 udma1 udma2 udma3 udma4 *udma5
前面打*的是当前传输模式
 
请问UDMA各模式对应的传输率分别是多少?
  答:UDMA2/4/5/6分别是Ultra ATA 33/66/100/133,即界面传输速度分别为33MB/s、66MB/s、100MB/s和133MB/s。不久会见到Serial ATA的硬盘(SATA),界面传输达到150MB/s。
  
 
更改硬盘的自检方式:
-l 查看文件系统信息(包括自检的挂载次数及天数
-c max-mount-counts 设置强制自检的挂载次数,如果开启,每挂载一次mount conut就会加1,超过次数就会强制自检
-i interval-between-checks[d|m|w] 设置强制自检的时间间隔[d天m月w周]
-m reserved-blocks-percentage 保留块的百分比
-j 将ext2文件系统转换为ext3类型的文件系统
-L volume-label 类似e2label的功能,可以修改文件系统的标签
-r reserved-blocks-count 调整系统保留空间
-o [^]mount-option[,...] 设置或清除默认挂载的文件系统选项
tune2fs -c 30 /dev/hda1 设置强制检查前文件系统可以挂载的次数
tune2fs -c -l /dev/hda1 关闭强制检查挂载次数限制。
tune2fs -i 10 /dev/hda1 10天后检查
tune2fs -i 1d /dev/hda1 1天后检查
tune2fs -i 3w /dev/hda1 3周后检查
tune2fs -i 6m /dev/hda1 半年后检查
tune2fs -i 0 /dev/hda1 禁用时间检查
 
 
查看Linux系统文件系统类型:
如果分区已经挂载:
#df -Th
 
如果分区未挂载:
#parted
然后再输入p就可看到了。
阅读(1147) | 评论(0) | 转发(0) |
0

上一篇:DDNS 配置

下一篇:新建swap分区

给主人留下些什么吧!~~