精华内容
下载资源
问答
  • 下面我们就来一窥物理文件的组织方式,我们用一个小索引就在一个块里面来证明。 一、准备数据640?wx_fmt=png 二、通过执行计划证明这个比较简单,我们使用using index type index 来访问索引,发现他们确实是相反。 ...

    我们知道普通索引数据的排列方式是从小到大的,而倒序索引应该是从大到小的,那么如何证明呢?
    下面我们就来一窥物理文件的组织方式,我们用一个小索引就在一个块里面来证明。

    一、准备数据
    640?wx_fmt=png

    二、通过执行计划证明
    这个比较简单,我们使用using index type index 来访问索引,发现他们确实是相反。

    640?wx_fmt=png

    三、通过工具证明
    执行 ./innblock tab_desc.ibd scan 16得到结果:
    640?wx_fmt=png

    通过INNODB_INDEXES可以看到这两个索引对应的ID确实是137/138
    通过命令 ./innblock tab_desc.ibd 5 16和 ./innblock tab_desc.ibd 6 16可以获得他们的逻辑链表信息如下:

    640?wx_fmt=png

    我们可以看到ID1普通索引逻辑链表信息为:

    INFIMUM ->126 ->142 ->158 .....->SUPREMUM
    而我们的反向索引逻辑链表信息为:
    INFIMUM ->222->206 ->190 .....->SUPREMUM

    那么我们分别来解读下数据因为普通索引的数据域排列方式就是:数据+主键 而int代表的是4字节那么
    id1的数据就是 (这里用到了一个自己的工具bcview方便观察,当然非要肉眼撸也是也可以的用hexdump):

    第一行 126字节后的4字节为:80000001
    current block:00000005--Offset:00126--cnt bytes:04--data is:80000001

    第二行 142字节后的4个字节:80000002
    current block:00000005--Offset:00142--cnt bytes:04--data is:80000002

    第三行 158字节后的4个字节:80000003
    current block:00000005--Offset:00158--cnt bytes:04--data is:80000003

    第四行 174字节后的4个字节:80000004
    current block:00000005--Offset:00174--cnt bytes:04--data is:80000004

    后面的我就不查询了可以看到是从小到大的。

    接下来我们分解下倒序索引的数据:

    第一行 222字节后的4字节为: 80000007
    current block:00000006--Offset:00222--cnt bytes:04--data is:80000007

    第二行 206字节后的4个字节: 80000006
    current block:00000006--Offset:00206--cnt bytes:04--data is:80000006

    第三行 190字节后的4个字节: 80000005
    current block:00000006--Offset:00190--cnt bytes:04--data is:80000005

    第四行 174字节后的4个字节: 80000004
    current block:00000006--Offset:00174--cnt bytes:04--data is:80000004

    因此我们得到验证,对于倒序索引而言其数据是在INFIMUM和SUPREMUM降序排列的。

    展开全文
  • 这里简单记录用到了我的一个工具详细见如下:innblock和bcview前者用于窥视...下面我们就来一窥物理文件的组织方式,我们用一个小索引就在一个块里面来证明。一、准备数据mysql>createtabletab_desc->(id1i...

    这里简单记录用到了我的一个工具详细见如下:

    innblock和bcview前者用于窥视innodb块的物理结构后者用于查看二进制文件免得肉眼撸。

    我们知道普通索引数据的排列方式是从小到大的,而倒序索引应该是从大到小的那么如何证明呢?

    下面我们就来一窥物理文件的组织方式,我们用一个小索引就在一个块里面来证明。

    一、准备数据

    mysql> create table tab_desc

    -> (id1 int,

    ->  id2 int,

    ->  key(id1),

    ->  key(id2 desc));

    Query OK, 0 rows affected (1.29 sec)

    mysql> select * from tab_desc;

    +------+------+| id1  | id2  |

    +------+------+

    |    1 |    1 ||    2 |    2 |

    |    3 |    3 ||    4 |    4 |

    |    5 |    5 ||    6 |    6 |

    |    7 |    7 |+------+------+

    二、通过执行计划证明

    这个比较简单我们使用using index type index 来访问索引发现他们确实是相反

    mysql> desc select id2 from tab_desc;

    +----+-------------+----------+------------+-------+---------------+------+---------+------+------+----------+-------------+| id | select_type | table    | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |

    +----+-------------+----------+------------+-------+---------------+------+---------+------+------+----------+-------------+

    |  1 | SIMPLE      | tab_desc | NULL       | index | NULL          | id2  | 5       | NULL |    7 |   100.00 | Using index |+----+-------------+----------+------------+-------+---------------+------+---------+------+------+----------+-------------+1 row in set, 1 warning (0.11 sec)

    mysql> select id2 from tab_desc;

    +------+| id2  |+------+|    7 ||    6 ||    5 ||    4 ||    3 ||    2 ||    1 |+------+7 rows in set (0.00 sec)

    mysql> desc select id1 from tab_desc;

    +----+-------------+----------+------------+-------+---------------+------+---------+------+------+----------+-------------+| id | select_type | table    | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |

    +----+-------------+----------+------------+-------+---------------+------+---------+------+------+----------+-------------+

    |  1 | SIMPLE      | tab_desc | NULL       | index | NULL          | id1  | 5       | NULL |    7 |   100.00 | Using index |+----+-------------+----------+------------+-------+---------------+------+---------+------+------+----------+-------------+1 row in set, 1 warning (0.00 sec)

    mysql> select id1 from tab_desc;

    +------+| id1  |+------+|    1 ||    2 ||    3 ||    4 ||    5 ||    6 ||    7 |+------+7 rows in set (0.00 sec)

    三、通过工具证明

    执行 ./innblock tab_desc.ibd scan 16得到结果

    ===INDEX_ID:136level0 total block is (1)

    block_no:         4,level:   0|*|

    ===INDEX_ID:137level0 total block is (1)

    block_no:         5,level:   0|*|

    ===INDEX_ID:138level0 total block is (1)

    block_no:         6,level:   0|*|

    通过INNODB_INDEXES可以看到这两个索引对应的ID确实是137/138

    |      136 | GEN_CLUST_INDEX |     1059 |    1 |        5 |       4 |     2 |              50 |

    |      137 | id1             |     1059 |    0 |        2 |       5 |     2 |              50 ||      138 | id2             |     1059 |    0 |        2 |       6 |     2 |              50 |

    通过命令 ./innblock tab_desc.ibd 5 16和 ./innblock tab_desc.ibd 6 16可以获得他们的逻辑链表信息如下:

    id1

    ==== Block list info ====

    -----Total used rows:9 used rows list(logic):

    (1) INFIMUM record offset:99 heapno:0 n_owned 1,delflag:N minflag:0 rectype:2(2) normal record offset:126 heapno:2 n_owned 0,delflag:N minflag:0 rectype:0 (3) normal record offset:142 heapno:3 n_owned 0,delflag:N minflag:0 rectype:0(4) normal record offset:158 heapno:4 n_owned 0,delflag:N minflag:0 rectype:0(5) normal record offset:174 heapno:5 n_owned 0,delflag:N minflag:0 rectype:0(6) normal record offset:190 heapno:6 n_owned 0,delflag:N minflag:0 rectype:0(7) normal record offset:206 heapno:7 n_owned 0,delflag:N minflag:0 rectype:0(8) normal record offset:222 heapno:8 n_owned 0,delflag:N minflag:0 rectype:0 (9) SUPREMUM record offset:112 heapno:1 n_owned 8,delflag:N minflag:0 rectype:3id2

    ==== Block list info ====

    -----Total used rows:9 used rows list(logic):

    (1) INFIMUM record offset:99 heapno:0 n_owned 1,delflag:N minflag:0 rectype:2(2) normal record offset:222 heapno:8 n_owned 0,delflag:N minflag:0 rectype:0 (3) normal record offset:206 heapno:7 n_owned 0,delflag:N minflag:0 rectype:0(4) normal record offset:190 heapno:6 n_owned 0,delflag:N minflag:0 rectype:0(5) normal record offset:174 heapno:5 n_owned 0,delflag:N minflag:0 rectype:0(6) normal record offset:158 heapno:4 n_owned 0,delflag:N minflag:0 rectype:0(7) normal record offset:142 heapno:3 n_owned 0,delflag:N minflag:0 rectype:0(8) normal record offset:126 heapno:2 n_owned 0,delflag:N minflag:0 rectype:0  (9) SUPREMUM record offset:112 heapno:1 n_owned 8,delflag:N minflag:0 rectype:3

    我们可以看到ID1普通索引逻辑链表信息为:

    INFIMUM ->126 ->142 ->158 .....->SUPREMUM

    而我们的反向索引逻辑链表信息为:

    INFIMUM ->222->206 ->190 .....->SUPREMUM

    那么我们分别来解读下数据因为普通索引的数据域排列方式就是:数据+主键 而int代表的是4字节那么

    id1的数据就是 (这里用到了一个自己的工具bcview方便观察,当然非要肉眼撸也是也可以的用hexdump):

    第一行 126字节后的4字节为:80000001

    current block:00000005--Offset:00126--cnt bytes:04--data is:80000001

    第二行 142字节后的4个字节:80000002

    current block:00000005--Offset:00142--cnt bytes:04--data is:80000002

    第三行 158字节后的4个字节:80000003

    current block:00000005--Offset:00158--cnt bytes:04--data is:80000003

    第四行 174字节后的4个字节:80000004

    current block:00000005--Offset:00174--cnt bytes:04--data is:80000004

    后面的我就不查询了可以看到是从小到大的。

    接下来我们分解下倒序索引的数据:

    第一行 222字节后的4字节为: 80000007

    current block:00000006--Offset:00222--cnt bytes:04--data is:80000007

    第二行 206字节后的4个字节: 80000006

    current block:00000006--Offset:00206--cnt bytes:04--data is:80000006

    第三行 190字节后的4个字节: 80000005

    current block:00000006--Offset:00190--cnt bytes:04--data is:80000005

    第四行 174字节后的4个字节: 80000004

    current block:00000006--Offset:00174--cnt bytes:04--data is:80000004

    因此我们得到验证,对于倒序索引而言其数据是在INFIMUM和SUPREMUM降序排列的。

    作者微信:gaopp_22389860

    展开全文
  • 下面我们就来一窥物理文件的组织方式,我们用一个小索引就在一个块里面来证明。一、准备数据二、通过执行计划证明这个比较简单,我们使用using index type index 来访问索引,发现他们确实是相反。三、通过工具证明...

    导 读

    作者:高鹏(重庆八怪)

    我们知道普通索引数据的排列方式是从小到大的,而倒序索引应该是从大到小的,那么如何证明呢?
    下面我们就来一窥物理文件的组织方式,我们用一个小索引就在一个块里面来证明。

    一、准备数据

    0aab2834204e45f61c7f3f1b3f92b67b.png

    二、通过执行计划证明

    这个比较简单,我们使用using index type index 来访问索引,发现他们确实是相反。

    82b2b430ec7c8317b76b1fc6e9a9289e.png

    三、通过工具证明

    执行 ./innblock tab_desc.ibd scan 16得到结果:

    06930faa7e9e1f96d2550717dd6e27bf.png

    通过INNODB_INDEXES可以看到这两个索引对应的ID确实是137/138

    通过命令  ./innblock tab_desc.ibd 5 16和  ./innblock tab_desc.ibd 6 16可以获得他们的逻辑链表信息如下:

    45932dd9fda1b6c5c141d787768172be.png

    我们可以看到ID1普通索引逻辑链表信息为:

    INFIMUM ->126 ->142 ->158 .....->SUPREMUM
    而我们的反向索引逻辑链表信息为:
    INFIMUM ->222->206 ->190 .....->SUPREMUM

    那么我们分别来解读下数据因为普通索引的数据域排列方式就是:数据+主键 而int代表的是4字节那么
    id1的数据就是 (这里用到了一个自己的工具bcview方便观察,当然非要肉眼撸也是也可以的用hexdump):

    • 第一行 126字节后的4字节为:80000001
      current block:00000005--Offset:00126--cnt bytes:04--data is:80000001

    • 第二行 142字节后的4个字节:80000002
      current block:00000005--Offset:00142--cnt bytes:04--data is:80000002

    • 第三行 158字节后的4个字节:80000003
      current block:00000005--Offset:00158--cnt bytes:04--data is:80000003

    • 第四行 174字节后的4个字节:80000004
      current block:00000005--Offset:00174--cnt bytes:04--data is:80000004

    后面的我就不查询了可以看到是从小到大的。

    接下来我们分解下倒序索引的数据:

    • 第一行 222字节后的4字节为: 80000007
      current block:00000006--Offset:00222--cnt bytes:04--data is:80000007

    • 第二行 206字节后的4个字节: 80000006
      current block:00000006--Offset:00206--cnt bytes:04--data is:80000006

    • 第三行 190字节后的4个字节: 80000005
      current block:00000006--Offset:00190--cnt bytes:04--data is:80000005

    • 第四行 174字节后的4个字节: 80000004
      current block:00000006--Offset:00174--cnt bytes:04--data is:80000004

    因此我们得到验证,对于倒序索引而言其数据是在INFIMUM和SUPREMUM降序排列的。

    对本文有任何疑问可扫码添加原文作者微信

    a7c301b77c564029da26484157361316.png

    b5af0acb42164503c905ec137996ec97.gif

    加入知数堂

    挑战40万+年薪!

    920bb662e5bea75a579792b88a1bc1de.png61289eb91371ef207a79309c1c6c7bb7.png7ebd200e9241930fe8b504e90d95fa01.png71ce83db31f8998cceb7f10dc6c8ffc2.png

    知数堂

    叶金荣与吴炳锡联合打造

    领跑IT精英培训

    行业资深专家强强联合,倾心定制

    MySQL实战/MySQL优化/MongoDB/

    Python/ SQL优化/Hadoop+ELK

    数门精品课程

    “阅读原文”可获更多正课试听视频

    密码:hg3h

    紧随技术发展趋势,定期优化培训教案

    融入大量生产案例,贴合企业一线需求

    社群陪伴学习,一次报名,可学1年

    DBA、开发工程师必修课

    上千位学员已华丽转身,薪资翻番,职位提升

    改变已悄然发生,你还在等什么?

    515f404aa08f9d9edb0dc4b22afd7c8f.png

    8a6da5cb189a95884d7859f3d38b75a0.gif扫码加入QQ技术交流群

    MySQL 8.0|MGR研究院-ZST

    (QQ群号:650149401)    

    d3eb82e20a543cf83c2bddb7c22cfb19.png

    展开全文
  • 文章目录文件管理文件属性文件内部数据组织结构操作系统对文件提供的功能文件如何存储在外存文件目录多级目录索引结点(FCB的改进)文件的物理结构链接分配一一隐式链接链接分配一―显式链接索引分配多层索引文件...

    文件管理

    计算机中存放了各种各样的文件,一个文件有哪些属性?
    文件内部的数据应该怎样组织起来?
    文件之间又应该又应该怎么组织起来?

    文件属性

    一个文件有哪些属性?

    文件名:由创建文件的用户决定文件名,主要是为了方便用户找到文件,同一目录下不允许有重名文件。

    标识符:一个系统内的各文件标识符唯一,对用户来说毫无可读性,因此标识符只是操作系统用于区分各个文件的一种内部名称。

    类型:指明文件的类型

    位置:文件存放的路径(让用户使用)、在外存中的地址(操作系统使用,对用户不可见)

    大小:指明文件大小创建时间、上次修改时间文件所有者信息

    保护信息:对文件进行保护的访问控制信息

    在这里插入图片描述

    文件内部数据的组织结构

    文件的组织结构像是设计模式中的组合模式一样, 一个个文件作为叶子节点, 目录作为父节点

    在这里插入图片描述

    操作系统对文件提供的功能

    创建文件(create系统调用)

    删除文件(delete系统调用)

    读文件(read系统调用)

    写文件(write系统调用)

    打开文件(open系统调用)

    关闭文件(close系统调用)

    文件如何存储在外存

    外存与内存一样,外存也是由一个个存储单元组成的,每个存储单元可以存储一定量的数据(如1B)。每个存储单元对应一个物理地址

    操作系统以“块”为单位为文件分配存储空间,因此即使一个文件大小只有10B,但它依然需要占用1KB的磁盘块。外存中的数据读入内存时同样以块为单位

    类似于内存分为一个个“内存块”,外存会分为一个个“块/磁盘块/物理块”。每个磁盘块的大小是相等的,每块一般包含2的整数幂个地址(如本例中,一块包含2^10个地址,即1KB)。同样类似的是,文件的逻辑地址也可以分为(逻辑块号,块内地址),操作系统同样需要将逻辑地址转换为外存的物理地址(物理块号,块内地址)的形式。块内地址的位数取决于磁盘块的大小

    文件目录

    在这里插入图片描述
    当我们双击“照片”后,操作系统会在这个目录表中找到关键字“照片”对应的目录项(也就是记录),然后从外存中将“照片”目录的信息读入内存,于是,“照片”目录中的内容就可以显示出来了。
    s
    目录文件表中的一条记录就是一个“文件控制块(FCB)

    FCB的有序集合称为“文件目录”,一个FCB就是一个文件目录项。FCB中包含了文件的基本信息﹖文件名、物理地址、逻辑结构、物理结构等),存取控制信息(是否可读/可写、禁止访问的用户名单等),使用信息(如文件的建立时间、修改时间等)。
    最重要,最基本的还是文件名、文件存放的物理地址。

    多级目录

    在这里插入图片描述
    用户((或用户进程)要访问某个文件时要用文件路径名标识文件,文件路径名是个字符串。各级目录之间用“/”隔开。从根目录出发的路径称为绝对路径。

    例如:自拍.jpg的绝对路径是“/照片/2015-08/自拍.jpg”

    系统根据绝对路径一层一层地找到下一
    级目录。刚开始从外存读入根目录的目录表;找到“照片”目录的
    存放位置后,从外存读入对应的目欢衣;X到才程h典?次读磁盘I/O操作。…P最后才找到文件“自拍.jpg”的存放位置。整个过程需要3次读磁盘I/o操作。

    很多时候,用户会连续访问同一目录内的多个文件(比如:接连查看2015-08"目录内的多个照片文件)显然,每次都从根目录开始查找,是很低效的。因此可以设置一个“当前目录”。

    例如,此时已经打开了“照片”的目录文件,也就是说,这张目录表已调入内存,那么可以把它设置为“当前目录”。当用户想要访问某个文件时,可以使用从当前目录出发的“相对路径”。

    在Linux中,“.”表示当前目录,因此如果“照片”是当前目录,则"自拍.jpg"的相对路径为:

    “./2015-08/自拍.jpg”。从当前路径出发,只需要查询内存中的“照片”目录表,即可知道"2015-08"目录表的存放位置,从外存调入该目录,即可知道“自拍.jpg”存放的位置了。

    可见,引入“当前目录”和“相对路径”后,磁盘l/o的次数减少了。这就提升了访问文件的效率。

    索引结点(FCB的改进)

    在这里插入图片描述
    思考有何好处?

    假设一个FCB是64B,磁盘块的大
    小为1KB,则每个盘块中只能存放16个FCB。若一个文件目录中共有
    640个目录项,则共需要占用640/16=40个盘块。因此按照某文件名检索该目录,平均需要查询320个目录项,平均需要启动磁盘20次(每次磁盘I/o读入一块)。

    若使用索引结点机制,文件名占14B,索引结点指针站2B,则每个盘块可存放64个目录项,那么按文件名检索目录平均只需要读320/64=5个磁盘块。显然,这将大大提升文件检索速度。

    文件的物理结构

    类似于内存分页,磁盘中的存储单元也会被分为一个个“块/磁盘块/物理
    块”。很多操作系统中,磁盘块的大小与内存块、页面的大小相同

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    那么文件在磁盘上被切割成一个个小磁盘块的时候是如何分配这些磁盘块的

    链接分配一一隐式链接

    在这里插入图片描述
    用户给出要访问的逻辑块号i,操作系统找到该文件对应的目录项(FCB)

    从目录项中找到起始块号(即o号块),将0号逻辑块读入内存,由此知道1号逻辑块存放的物理块号,于是读入1号逻辑块,再找到2号逻辑块的存放位置…….以此类推。
    因此,读入i号逻辑块,总共需要i+1次磁盘I/o.

    结论:采用链式分配(隐式链接)方式的文件,只支持顺序访问,不支持随机访问,查找效率低。另外,指向下一个盘块的指针也需要耗费少量的存储空间。

    采用隐式链接的链接分配方式,很方便文件拓展。另外,所有的空闲磁盘块都可以被利用,不会有碎片问题,外存利用率高。

    链接分配一―显式链接

    把用于链接文件各物理块的指针显式地存放在一张表中。即文件分配表(FAT,File Allocation Table)
    在这里插入图片描述
    假设某个新创建的文件“aaa”依次存放在磁盘块2>5>0→1
    假设某个新创建的文件“bbb”依次存放在磁盘块4>23 >3
    注意:一个磁盘仅设置一张FAT。开机时,将FAT读入内存,并常驻内存。FAT的各个表项在物理上连续存储,且每一个表项长度相同,因此“物理块号”字段可以是隐含的。

    用户给出要访问的逻辑块号i,操作系统找到该文件对应的目录项(FCB) 在这里插入图片描述

    从目录项中找到起始块号,若i>o,则查询内存中的文件分配表FAT,往后找到i号逻辑块对应的物理块号。逻辑块号转换成物理块号的过程不需要读磁盘操作。
    结论:采用链式分配(显式链接)方式的文件,支持顺序访问,也支持随机访问(想访问i号逻辑块时,并不需要依次访问之前的0~i-1号逻辑块),由于块号转换的过程不需要访问磁盘,因此相比于隐式链接来说,访问速度快很多。
    显然,显式链接也不会产生外部碎片,也可以很方便地对文件进行拓展。

    索引分配

    索引分配允许文件离散地分配在各个磁盘块中,系统会为每个文件建立一张索引表,索引表中记录了文件的各个逻辑块对应的物理块(索引表的功能类似于内存管理中的页表――建立逻辑页面到物理页之间的映射关系)。索引表存放的磁盘块称为索引块。文件数据存放的磁盘块称为数据块。
    在这里插入图片描述
    假设某个新创建的文件“aaa”的数据依次存放在磁盘块2>5→13>9。7号磁盘块作为“aaa”的索引块,索引块中保存了索引表的内容。

    注:在显式链接的链式分配方式中,文件分配表FAT是一个磁盘对应一张。而索引分配方式中,索引表是一个文件对应一张。

    从目录项中可知索引表存放位置,将索引表从外存读入内存,并查找索引表即可只i号逻辑块在外存中的存放位置。

    可见,索引分配方式可以支持随机访问。文件拓展也很容易实现(只需要给文件分配一个空闲块,并增加一个索引表项即可)但是索引表需要占用一定的存储空间

    如果一个文件的大小超过了256块,那么一个磁盘块是装不下文件的整张索引表的,如何解决这个问题?

    多层索引

    ①链接方案:如果索引表太大,一个索引块装不下,那么可以将多个索引块链接起来存放。
    在这里插入图片描述
    假设磁盘块大小为1KB,一个索引表项占4B,则一个磁盘块只能存放256个索引项。
    若一个文件大小为256256KB =65,536 KB =64MB
    该文件共有256
    256个块,也就对应256*256个索引项,也就需要256个索引块来存储,这些索引块用链接方案连起来。
    若想要访问文件的最后一个逻辑块,就必须找到最后一个索引块(第256个索引块),而各个索引块之间是用指针链接起来的,因此必须先顺序地读入前255个索引块。
    这显然是很低效的。如何解决呢?

    ②多层索引:建立多层索引(原理类似于多级页表)。使第一层索引块指向第二层的索引块。还可根据文件大小的要求再建立第三层、第四层索引块。

    在这里插入图片描述
    假设磁盘块大小为1KB,一个索引表项占4B,则一个磁盘块只能存放256个索引项。
    若某文件采用两层索引,则该文件的最大长度可以到2562561KB =65,536 KB =64MB
    可根据逻辑块号算出应该查找索引表中的哪个表项。如:要访问1026号逻辑块,则
    1026/256=4,1026%256= 2
    因此可以先将一级索引表调入内存,查询4号表项,将其对应的二级索引表调入内存,再查询二级索引表的2号表项即可知道1026号逻辑块存放的磁盘块号了。访问目标数据块,需要3次磁盘I/O。

    文件共享

    注意:多个用户共享同一个文件,意味着系统中只有“一份”文件数据。并且只要某个用户修改了该文件的数据,其他用户也可以看到文件数据的变化。
    如果是多个用户都“复制”了同一个文件,那么系统中会有“好几份”文件数据。其中一个用户修改了自己的那份文件数据,对其他用户的文件数据并没有影响。

    基于索引结点的共享方式(硬链接)

    知识回顾:索引结点,是一种文件目录瘦身策略。由于检索文件时只需用到文件名,因此可以将除了文件名之外的其他信息放到索引结点中。这样目录项就只需要包含文件名、索引结点指针。

    索引结点中设置一个链接计数变量count,用于表示链接到本索引结点上的用户目录项数。
    若count =2,说明此时有两个用户目录项链接到该索引结点上,或者说是有两个用户在共享此文件
    在这里插入图片描述

    基于符号链的共享方式(软链接)

    当User3访问“ccc”时,操作系统判断文件“ccc”属于Link类型文件,于是会根据其中记录的路径层层查找目录,最终找到User1的目录表中的“aaa”表项,于是就找到了文件1的索引结点。
    在这里插入图片描述

    文件保护

    口令保护

    为文件设置一个“口令”(如: abc112233),用户请求访问该文件时必须提供“口令”。
    口令一般存放在文件对应的FCB或索
    引结点中。用户访问文件前需要先输入“口令”,操作系统会将用户提供的口令与FCB中存储的口令进行对比,如果正确,则允许该用户访问文件
    优点:保存口令的空间开销不多,验证口令的时间开销也很小。缺点:正确的“口令”存放在系统内部,不够安全。

    加密保护

    使用某个“密码”对文件进行加密,在访问文件时需要提供正确的“密码”才能对文件进行正确的解密。
    Eg:一个最简单的加密算法―—异或加密
    假设用于加密/解密的“密码”为“01001”

    在这里插入图片描述
    优点:保密性强,不需要在系统中存储“密码”
    缺点:编码/译码,或者说加密/解密要花费一定时间。

    访问控制

    在每个文件的FCB(或索引结点〉中增加一个访问控制列表(Access-Control List,ACL),该表中记录了各个用户可以对该文件执行哪些操作。

    在这里插入图片描述
    在这里插入图片描述
    在每个文件的FCB(或索引结点)中增加一个访问控制列表(Access-Control List, ACL),该表中记录了各个用户可以对该文件执行哪些操作。
    精简的访问列表:以“组”为单位,标记各“组”用户可以对文件执行哪些操作。
    如:分为系统管理员、文件主、文件主的伙伴、其他用户几个分组。
    当某用户想要访问文件时,系统会检查该用户所属的分组是否有相应的访问权限。

    在这里插入图片描述

    文件系统层次结构

    在这里插入图片描述
    用一个例子来辅助记忆文件系统的层次结构:
    假设某用户请求删除文件“D:/工作目录/学生信息.xlsx”的最后100条记录。1.用户需要通过操作系统提供的接口发出上述请求――用户接口
    2. 由于用户提供的是文件的存放路径,因此需要操作系统一层一层地查找目录,找到对应的目录项――文件目录系统
    3.不同的用户对文件有不同的操作权限,因此为了保证安全,需要检查用户是否有访问权限―一存取控制模块(存取控制验证层)
    4.验证了用户的访问权限之后,需要把用户提供的“记录号”转变为对应的逻辑地址――逻辑文件系统与文件信息缓冲区
    5.知道了目标记录对应的逻辑地址后,还需要转换成实际的物理地址――物理文件系统6.要删除这条记录,必定要对磁盘设备发出请求――设备管理程序模块
    7.删除这些记录后,会有一些盘块空闲,因此要将这些空闲盘块回收――辅助分配模块

    展开全文
  • 在UNIX的文件系统中,文件的物理存储结构是以索引方式组织的。如果将存储结构改为串联方式,即在每个数据块的末尾加上一个指向下一个数据块的指针,则文件系统应做哪些修改?
  • Oracle体系结构逻辑存储结构(扩展)数据数据区段数据索引段回滚段临时段表空间集中默认创建表空间SYSTEM表空间SYSAUX表空间UNDO表空间USERS表空间TEMP表空间注意物理存储结构(扩展)主要文件数据文件表空间...
  • 存储引擎InnoDB的索引

    2020-06-05 15:37:41
    我们常用MySQL默认存储引擎就是 InnoDB,在 InnoDB 里面,它是以主键为索引来组织数据的存储,所以所以索引文件数据文件是同一个文件,都在 .ibd 文件里面, 在 InnoDB 主键索引的叶子节点上,它直接存储...
  • 操作系统——文件链接组织方式存在的问题及解决方法一、...文件的物理结构直接与外存的组织方式有关,不同的外存分配方式,将形成不同的文件物理结构,文件有如下三种外存分配方式,同时对应了三种文件的物理存储结构。
  • 从文件在存储器上的存放方式来看,文件的物理结构往往可区分为三类,即顺序组织,随机组织和链组织。B+树适用于组织随机组织索引结构,m阶B+树每个结点至多有m个儿子,除根结点外每个结点至少有⌈m/2⌉个儿子,根...
  • 为什innodb的索引叶子节点存的是主键,而不是像myisam一样存数据的物理地址指针?如果存的是物理地址指针不就不需要二次查找了吗,根据myisam和innodb数据存储方式的差异去想Imyisam索引文件数据文件是分离的,...
  • 数据库逻辑构造是指描述数据组织方式的一组逻辑概念及它们之间关系,表空间是数据库逻辑构造一个重要组件,表空间可以存放各种。 1.表空间分类 永久表空间:存储数据库中需要永久化存储对象,比如二维表、...
  • 这篇主要介绍 MySQL 两种常用引擎,MyISAM 和 InnoDB 的索引组织方式,了解这些存储方式,对数据库优化很有帮助。MySQL 的索引按照存储方式分为两类:聚集索引:也称 Clustered Index。是指关系表记录的物理顺序与...
  • 一、按文件结构分 1、无结构文件(流式文件) 文件内部数据由一系列二进制流或字符流组成 2、有结构文件(记录式文件) ...1)顺序文件的排列方式 2)顺序文件的特性及优缺点 2、索引..
  • 文件的逻辑结构(文件组织):是从用户观点出发所观察到的文件组织形式,即文件是由一系列的逻辑记录组成的,是用户可以直接处理的数据及其结构,它独立于文件的物理特性。(顺序文件、索引文件、索引顺序文件) ...
  • 多用户多级目录文件系统实现

    热门讨论 2009-06-25 21:15:34
    通过具体的文件存储空间的管理、文件的物理结构、目录结构和文件操作的实现,加深对文件系统内部功能和实现过程的理解。 二、课程设计的要求与数据 1. 在内存中开辟一个虚拟磁盘空间作为文件存储器,在其上实现一...
  • 6 文件 磁盘管理

    2018-12-09 09:32:30
      文件管理:把所管理的程序和数据组织成一系列的文件,并...文件的物理结构: 用文件的存储方式分类:顺序结构;链接式结构;索引式结构。 外存分配方式: 1)连续分配 为每一个文件分配一组相邻的盘块...
  • 文件系统:逻辑结构

    2021-01-03 21:49:39
    从用户观点出发所观察到的文件组织形式,是用户可以直接处理的数据及其结构,它独立于文件的物理特性,又称为文件组织(File Organization) 有结构文件 由一个记录以上构成的文件,又称为记录式文件 定长记录 每...
  • 文件系统知识点总结

    2020-05-14 17:00:25
    文件的逻辑结构 大体上分为有结构文件和无结构文件。 无结构文件: 如windows下的.txt文件就是无结构的, 文件内部的数据就是一系列的二进制流或者字符流组成, 又称为流式文件。 有结构文件: 数据按记录的形式有...
  • 文件系统实现

    2020-08-20 20:39:24
    知识结构 目录物理实现 哈希 线性表 文件实现 文件分配方式 ...索引分配 ...多层索引 混合索引 ...目录物理实现 ...一个被存储的表项包括存储文件名和数据块指针,...线性表:实现简单,采用链表还可以减少删除文件的时间,但
  • 数据的物理模型即指数据的存储结构如对数据库物理文件索引 文件的组织方式文件的存取路径内存的管理等物理模型不仅 与数据库管理系统有关还和操作系统甚至硬件有关物理模型对用 户是不可见的 ? 按关系模型组织的...
  • 从文件在存储器上的存放方式来看,文件的物理结构往往可区分为三类,即_(3)_,_(4)_和_(5)_。B+ 树适用于组织_(6)_的索引结构,m 阶B+ 树每个结点至多有_(7)_个儿子,除根结点外每个结点至少有 (8) 个儿子,根结点...
  • 外存的组织方式:连续组织方式、链接组织方式索引组织方式、NTFS的文件组织单位 NTFS中,以卷为单位,一个卷一张主控文件表MFT,减少了磁盘访问次数。 文件存储空间管理:空闲表法、空闲链表法、位示图法、成组...
  • oracle数据库应用

    2020-09-28 17:37:04
    数据库逻辑结构是指描述数据组织方式的一组逻概念及他们之间关系.表空间有一个或者多个数据文件组成 1.1表空间分类 类别 说明 永久性表空间 一般保存表、视图、过程和索引数据.SYSTEM、SYSAUX、...
  • 操作系统(七)

    2020-02-05 22:08:42
    文件管理 研究文件系统两个角度:用户的角度、操作系统的角度 文件的分类 按文件的用途分类 系统文件:操作系统和各种应用程序和数据所组成的文件 ...物理结构:顺序文件、链接文件和索引文件等 UNIX操作系...
  • 管道内部结构

    2016-07-18 00:19:23
    管道内部组织方式 在 Linux 中,管道实现并没有使用专门的数据结构,而是借助了文件系统file结构和VFS的索引节点inode。通过将两个 file 结构指向同一个临时 VFS 索引节点,而这个 VFS 索引节点又指向一个...
  • OS对磁盘块管理

    2020-05-12 17:18:00
    这部分内容属于操作系统对非空闲磁盘块的管理(就是那些存放了文件数据的磁盘块),即文件的物理结构,文件如何存放在外存中、文件分配方式。主要有三种:连续、链接和索引组织方式。 【题目】 在一个操作系统中,...
  • 关系数据库是按照二维表结构方式组织的数据集合,每个表体现了集合理论中定义数学概念————关系。 Oracle数据库(Database)是一个数据容器,它包含了表、索引、视图、过程、函数、包等对象,并对这些对象进行...
  • 3内模式是数据库在物理存储方面的描述,定义所有内部记录类型、索引文件的组织方式,以及数据控制方面的细节。4模式/内模式映像存在于概念级和内部级之间,用于定义概念模式和内模式之间的对应性。5外模式/模式...
  • Linux中对物理外存上的数据块采用的组织管理方式是借助称为索引节点(inode)的数据结构,因此当应用进程要与具体逻辑文件系统进行数据存取时,相应逻辑文件系统将需要提供操作例程接口来实施具体...

空空如也

空空如也

1 2 3 4 5 ... 9
收藏数 162
精华内容 64
关键字:

文件的物理组织方式索引数据