块存储硬盘

A. 不跨块存储什么意思

不跨块存储意思是：传统磁盘阵列：基本磁盘阵列都是商用产品，而每个厂家基本上都做好了图形化管理界面，因此对于日常的运维操作，基本上只要在图形化界面上面进行点选，就可以完成。并且一旦出现问题，还可以开CASE寻求厂家协助。毕竟存储的是数据，是企业的核心生产力，一旦数据丢失，或者不可访问，非同小可。
软件定义存储：有很多ceph、swift等的开源分布式存储软件，可以自己搭建。最稳定的是软硬一体的设备（但是本质上还是存储品牌绑定，跨品牌不兼容的问题），坑最多的是纯软件的版本（例如VSAN，不但购买的硬件必须是在VSAN的兼容性列表里面的，而且对于驱动、版本等需要匹配到微码级别，否则可能会出现兼容性问题，开CASE都解决不了），而可扩展性最好但是易用性最差的当然是开源的版本。（基本上都要命令行操作，而且需要具备能力非常强的运维团队，否则一旦出现故障，是没有任何外部里能可以支援的）

B. 对象存储、文件存储和块存储有什么区别

区别如下：

1、速度不同

块存储：低延迟（10ms），热点突出；

文件存储：不同技术各有不同；

对象存储：100ms-1s，冷数据；

2、可分步性不同

块存储：异地不现实；

文件存储：可分布式，但有瓶颈；

对象存储：分步并发能力高；

3、文件大小不同

块存储：大小都可以，热点突出；

文件存储：适合大文件；

对象存储：适合各种大小；

4、接口不同

块存储：Driver，kernel mole ；

文件存储：POSIX；

对象存储：Restful API ；

5、典型技术不同

块存储：SAN；

文件存储：HDFS，GFS；

对象存储：Swift，Amazon S3；

6、适合场景不同

块存储：银行；

文件存储：数据中心；

对象存储：网络媒体文件存储；

(2)块存储硬盘扩展阅读：

文件存储的优缺点：

优点

（1）、造价低：随便一台机器就可以，另外普通的以太网就可以，根本不需要专用的SAN网络，所以造价低。

（2）、方便文件共享。

缺点

（1）、读写速率低，传输速率慢：以太网，上传下载速度较慢，另外所有读写都要1台服务器里面的硬盘来承受，相比起磁盘阵列动不动就十几上百块硬盘同时读写，速率慢了许多。

C. 2020-12-02 硬盘如何存储文件

系统中所有内容是以文件（文件夹是特殊的文件）存在的，而文件分为属性（元信息）和内容两部分，磁盘一部分被操作系统虚拟为块用来存储数据，同时也分出一部分虚拟为Inode用来存储文件属性，这样磁盘就分为块区和inode区。

扇区：磁盘存储数据的最小物理单元，每个扇区很小512字节左右。
读取数据：OS要想读取磁盘数据，首先让磁头径向寻道（最慢），然后旋转磁盘（较快），使磁头到达目标扇区，开始读取数据。

磁盘块：OS日常工作中，一个扇区的512字节数据很小，不足以支撑绝大部分工作场景，所以需要频繁读取单个扇区，而磁盘读取数据速度相对CPU处理太慢了，所以读磁盘时一次就多拿出几个扇区（临近的，无需耗费额外时间）的数据，于是在OS层面逻辑虚拟出磁盘块（簇）的概念，一个磁盘块一般对应8个连续扇区（也可4、16个等，由OS决定），这样OS层面就使用磁盘块作为最小数据存储单元。
这样的好处当然是更高效，缺点则是会？

inode：用于存储文件的元信息（除名称外的所有属性，名称存在文件夹的内容中）
Inode number is also known as index number. An inode is a unique number assigned to files and directories while it is created. The inode number will be unique to entire filesystem.

Disk inodes contain the following information:

Owner identifier
Type of file (regular, directory, character or block device)
Access permissions
Times and dates
· file creation time

· last file access time

· last inode modification time

Number of links to the file
Array of pointers to data blocks on disk
File size (in bytes, sometimes also in blocks)

文件：
上文提及文件属性存在磁盘inode区的inode（每个都有编号）内，而内容存储在块区的块中。

文件夹：
作为特殊文件，其组织文件及目录，属性也是存在inode内，而存储的内容是一个包含多个{ 文件名:对应inode Id} 的列表，内容亦存在块区的块中。

这样在OS中查看一个文件（比如/etc/fstab）的内容，大概是：
首先OS获取到根目录的inodeId >在inode区中读取到其属性（某项是内容所在块）>在块区读取到根目录内容>在内容中找到名为/etc对应发inodeId>/etc在inode区的属性>读取到块中/etc的内容（包含/etc/fstab对应inodeId）>/etc/fstab Inode Id > 在inode区读取到/etc/fstab属性 >/etc/fstab块。

可能有误，望指点。

Within each file system, the mapping from names to blocks is handled through a structure called an i-node. There's a pool of these things near the "bottom" (lowest-numbered blocks) of each file system (the very lowest ones are used for housekeeping and labeling purposes we won't describe here). Each i-node describes one file. File data blocks (including directories) live above the i-nodes (in higher-numbered blocks).

Every i-node contains a list of the disk block numbers in the file it describes. (Actually this is a half-truth, only correct for small files, but the rest of the details aren't important here.) Note that the i-node does not contain the name of the file.

Names of files live in directory structures. A directory structure just maps names to i-node numbers. This is why, in Unix, a file can have multiple true names (or hard links); they're just multiple directory entries that happen to point to the same i-node.

refer: https://unix.stackexchange.com/questions/432655/why-does-using-indirect-pointers-in-inodes-not-incur-the-same-amount-of-space

less:by direct list blocks in node?.
large :by two-level indirect block
larger : multi-level indirect block.

The original hierarchy of the inodes levels works roughly like this:

You can store one or a few block numbers directly in the inode. This means you use a few bytes more for the inode, but for small files, you don't have to allocate a complete block, which is mostly empty.

The next level is one indirection: You allocate a block to store the block pointers. Only the address of this indirect block is stored in the inode. This doesn't use somehow "less space", and most filesystems, even early ones, worked like that (have a pointer near the inode/filename which points to a block, which stores the block numbers of the file).

But what do you do when the space in this block runs out? You have to allocate another block, but where do you store the reference to this block? You could just add those references to the inode, but to store largers files, the inode would get large. And you want small inodes, so as many as possible inodes can fit into a single block (less disk access to read more inodes).

So you use a two-level indirect block: You just add one pointer to the inode, then you have a whole block to store pointers to indirect blocks, and the indirect blocks store the block address of the file itself.

And so on, you can add higher-level indirect blocks, or stop at some stage, until you reach the maximal size of a file possible with the structure you want.

So the point is not "use up less space in total", but "use a scheme that uses blocks efficiently for the expected distribution a files wrt. to size, i.e. many small files, some larger files, and very few huge files".

Page tables on the other hand work very differently.

Edit

To answer the questions in the comment:

Data blocks are of fixed sizes (originally 512 bytes, IIRC), which is a multiple of the block size of the underlying harddisks. So data block size can't "decrease".

As I tried to describe above, the whole point of having the inodes not use up too much space is to make inode access faster (or, alternatively, make caching inodes use up less memory - back then when the unix file system with inodes was invented, computers had a lot less memory than today). It's not about somehow saving space in total. As you say yourself, everything has to be stored somewhere, and if it doesn't use up space at location X, it will use up space at location Y.

Just adding a variable number of block pointers to the inode is not practical, because the inode must take up a fixed amount of space - you want to use the inode number to calculate the block address and the offset inside the block where the inode information is stored. You can't do that if every inode has a different size. So there must be some form of indirection.

Page tables work differently because hardware implements them differently - that's just how it is. The hierarchy has a fixed depth, always the same (though sometimes configurable. And while reading a block from disk is slow, that doesn't matter for page tables. So the design issues are completely different.

http://www.cems.uwe.ac.uk/~irjohnso/coursenotes/lrc/internals/filestore/fs3.htm

Assuming, for the purposes of illustration, that each disk data block is 1024 bytes in size, then these ten data block pointers will allow files to be created that are up to 10 Kb in size. As you can see, for the large majority of files it should be possible to access the data with nothing more than a direct lookup required to find the data block that contains any particular data byte.

With this scheme, once a file has grown to 10 Kb, there are only three block pointers in the inode left to use, whatever the eventual size of the file. Obviously, some new arrangement must be found so that the three remaining block pointers will suffice for any realistic file size, while at the same time not degrading the data access time too much.

This goal is achieved by using the idea of indirect block pointers. Specifically, when an 11th data block needs to be allocated to the file, the 11th inode block pointer is used, but instead of pointing to the block which will contain the data, the 11th pointer is a single indirect pointer which points to a data block filled with a list of direct block pointers. In our example, if we assume that a data block number is a 32-bit value, then a list of 256 of them will fit into the single indirect block. This list will point directly to the data blocks for the next 256 Kb of our file. This means that with 11 block pointers in the inode, files of up to 266 Kb (10 + 256) can be created. True, it takes a little longer to access the data beyond the first 10 Kb in the file, but it takes only one extra disk block read to find the position on the disk of the required data.

For files bigger than 266 Kb the double indirect (12th) inode block pointer is used. This is the same idea as the previous inode pointer except that the double indirect pointer points to a list of pointers in a data block, each of which is itself a single indirect block pointer which points to a list of 256 direct block pointers. This means that the 12th inode block pointer gives access to the next 65536 Kb (256x256) of data in our file.

By now, you should be able to spot the pattern and see that when the file grows bigger than 64 Mb (actually 65802 Kb), the inode's 13th data block pointer will be used, but this time as a triple indirect pointer, which will give access to a staggering 16 Gb (256x256x256 Kb) of extra file space. A single file bigger than 16Gb sounds huge. However, even though the calculation we have just done suggests that this file size is possible with the inode layout as given, in fact there are other factors which limit the maximum size of a file to a smaller value than this. For example, the size of a file, in bytes, is stored separately in its inode in a field of type unsigned long. This is a 32-bit number which limits the size of a file to 4 Gb, so that 13 data block pointers in an inode really are enough.

10.4. How a file gets looked up
Now we can look at the file system from the top down. When you open a file (such as, say, /home/esr/WWW/ldp/fundamentals.xml) here is what happens:

Your kernel starts at the root of your Unix file system (in the root partition). It looks for a directory there called ‘home’. Usually ‘home’ is a mount point to a large user partition elsewhere, so it will go there. In the top-level directory structure of that user partition, it will look for a entry called ‘esr’ and extract an i-node number. It will go to that i-node, notice that its associated file data blocks are a directory structure, and look up ‘WWW’. Extracting that i-node, it will go to the corresponding subdirectory and look up ‘ldp’. That will take it to yet another directory i-node. Opening that one, it will find an i-node number for ‘fundamentals.xml’. That i-node is not a directory, but instead holds the list of disk blocks associated with the file.

The surface area of your disk, where it stores data, is divided up something like a dartboard — into circular tracks which are then pie-sliced into sectors. Because tracks near the outer edge have more area than those close to the spindle at the center of the disk, the outer tracks have more sector slices in them than the inner ones. Each sector (or disk block ) has the same size, which under modern Unixes is generally 1 binary K (1024 8-bit bytes). Each disk block has a unique address or disk block number .

Unix divides the disk into disk partitions . Each partition is a continuous span of blocks that's used separately from any other partition, either as a file system or as swap space. The original reasons for partitions had to do with crash recovery in a world of much slower and more error-prone disks; the boundaries between them rece the fraction of your disk likely to become inaccessible or corrupted by a random bad spot on the disk. Nowadays, it's more important that partitions can be declared read-only (preventing an intruder from modifying critical system files) or shared over a network through various means we won't discuss here. The lowest-numbered partition on a disk is often treated specially, as a boot partition where you can put a kernel to be booted.

Each partition is either swap space (used to implement virtual memory ) or a file system used to hold files. Swap-space partitions are just treated as a linear sequence of blocks. File systems, on the other hand, need a way to map file names to sequences of disk blocks. Because files grow, shrink, and change over time, a file's data blocks will not be a linear sequence but may be scattered all over its partition (from wherever the operating system can find a free block when it needs one). This scattering effect is called fragmentation .

Within each file system, the mapping from names to blocks is handled through a structure called an i-node . There's a pool of these things near the "bottom" (lowest-numbered blocks) of each file system (the very lowest ones are used for housekeeping and labeling purposes we won't describe here). Each i-node describes one file. File data blocks (including directories) live above the i-nodes (in higher-numbered blocks).

Every i-node contains a list of the disk block numbers in the file it describes. (Actually this is a half-truth, only correct for small files, but the rest of the details aren't important here.) Note that the i-node does not contain the name of the file.

Names of files live in directory structures . A directory structure just maps names to i-node numbers. This is why, in Unix, a file can have multiple true names (or hard links ); they're just multiple directory entries that happen to point to the same i-node.

In the simplest case, your entire Unix file system lives in just one disk partition. While you'll see this arrangement on some small personal Unix systems, it's unusual. More typical is for it to be spread across several disk partitions, possibly on different physical disks. So, for example, your system may have one small partition where the kernel lives, a slightly larger one where OS utilities live, and a much bigger one where user home directories live.

The only partition you'll have access to immediately after system boot is your root partition , which is (almost always) the one you booted from. It holds the root directory of the file system, the top node from which everything else hangs.

The other partitions in the system have to be attached to this root in order for your entire, multiple-partition file system to be accessible. About midway through the boot process, your Unix will make these non-root partitions accessible. It will mount each one onto a directory on the root partition.

For example, if you have a Unix directory called <tt class="filename">/usr</tt>, it is probably a mount point to a partition that contains many programs installed with your Unix but not required ring initial boot.

D. 块存储、文件存储、对象存储这三者的本质差别是什么

一、概念及区别

针对不同的应用场景，选择的分布式存储方案也会不同，因此有了对象存储、块存储、文件系统存储。这三者的主要区别在于它们的存储接口：

1. 对象存储:

也就是通常意义的键值存储，其接口就是简单的GET,PUT,DEL和其他扩展，

2. 块存储:

这种接口通常以QEMU Driver或者Kernel Mole的方式存在，这种接口需要实现Linux的BlockDevice的接口或者QEMU提供的BlockDriver接口，如Sheepdog，AWS的EBS，青云的云硬盘和阿里云的盘古系统，还有Ceph的RBD(RBD是Ceph面向块存储的接口)

3. 文件存储:

通常意义是支持POSIX接口，它跟传统的文件系统如Ext4是一个类型的，但区别在于分布式存储提供了并行化的能力，如Ceph的CephFS(CephFS是Ceph面向文件存储的接口)，但是有时候又会把GFS，HDFS这种非POSIX接口的类文件存储接口归入此类。

二、IO特点

按照这三种接口和其应用场景，很容易了解这三种类型的IO特点，括号里代表了它在非分布式情况下的对应:1. 对象存储(键值数据库):

接口简单，一个对象我们可以看成一个文件，只能全写全读，通常以大文件为主，要求足够的IO带宽。

2. 块存储(硬盘):

它的IO特点与传统的硬盘是一致的，一个硬盘应该是能面向通用需求的，即能应付大文件读写，也能处理好小文件读写。但是硬盘的特点是容量大，热点明显。因此块存储主要可以应付热点问题。另外，块存储要求的延迟是最低的。

3. 文件存储(文件系统):

支持文件存储的接口的系统设计跟传统本地文件系统如Ext4这种的特点和难点是一致的，它比块存储具有更丰富的接口，需要考虑目录、文件属性等支持，实现一个支持并行化的文件存储应该是最困难的。但像HDFS、GFS这种自己定义标准的系统，可以通过根据实现来定义接口，会容易一点。

因此，这三种接口分别以非分布式情况下的键值数据库、硬盘和文件系统的IO特点来对应即可。至于冷热、快慢、大小文件而言更接近于业务。但是因为存储系统是通用化实现，通常来说，需要尽量满足各种需求，而接口定义已经一定意义上就砍去了一些需求，如对象存储会以冷存储更多，大文件为主。

E. 固态硬盘盒是什么 固态硬盘盒介绍

1、固态硬盘（Solid State Disk、Solid State Drive，简称SSD，准确的技术称呼应为固态驱动器）是一种基于永久性存储器，如闪存，或非永久性存储器，同步动态随机存取存储器（SDRAM）的计算机外部存储设备。固态硬盘用来在便携式计算机中代替常规硬盘。虽然在固态硬盘中已经没有可以旋转的盘状结构，但是依照人们的命名习惯，这类存储器仍然被称为“硬盘”。

2、由于固态硬盘技术与传统硬盘技术不同，所以产生了不少新兴的存储器厂商。厂商只需购买NAND Flash存储器，再配合适当的控制芯片，就可以制造固态硬盘了。新一代的固态硬盘普遍采用SATA-2接口。

3、固态硬盘大部分被制作成与常规硬盘相同的外形，例如常见的1.8英寸、2.5英寸或3.5英寸规格，并采用了相互兼容的接口；但有些固态硬盘也使用 PCI Express 或是 Express Card 作为接口来突破现有硬盘传输接口的速度，或是在有限空间（如笔记本电脑）中置放固态硬盘。

4、固态硬盘采用的存储块存储数据，类似U盘的结构原理。普通硬盘采用的是磁盘介质方式。存在机械结构带动磁盘转动来达到工作的。

F. 云存储和传统硬盘存储有哪些优缺点

给个水一点的回答,考虑到刻录机的老化和兼容性之类的问题,普通光盘的存储时间应该不如硬盘,机械硬盘不如u盘和ssd,光盘当然是避光低温保存最好。云存储的优点就是存储方便分享也方便,共有部分的数据冗余度低,缺点就是对网络依赖大,对政策依赖大,安全性值得担忧。
采纳哦

G. 一个文件如何被分块存储在磁盘上

数据存储在硬盘的时候都以簇位单位簇的配置Windows9x/Me系统中常用的文件簇通常为FAT16或者FAT32格式比如一个256M的硬盘空间可以有数种配置簇的方式：簇大小＝4KB：256MB/4KB＝655356个簇簇大小＝8KB：256MB/8KB＝32768个簇簇大小＝16KB：256MB/16KB＝16384个簇簇大小＝32KB：256MB/32KB＝8192个簇对于WindowsNT/2000/XP特有的NTFS文件系统来说，虽然也是采用簇方式来存储数据，但它却和FAT16/FAT32有着明显的不同。当分区空间大于2GB的时候，无论硬盘有多大，簇的大小一律维持在4KB。由于簇容量小，所以无论存储何种类型的文件都不会浪费太多的硬盘空间，这也使得整个硬盘的空间利用率得到了极大的提高。

H. 什么是系统在硬盘上开辟的一块储存空间，用于在cpu与内存之间快速交换数据

虚拟内存。
当计算机随机存储器RAM不足时，操作系统用虚拟存储器进行补偿，缓解内存紧张，虚拟内存由硬件和操作系统自动实现存储信息调度和管理的。
虚拟内存越高系统越流畅，它使得应用程序认为它拥有连续的可用的内存一个连续完整的地址空间，而实际上它通常是被分隔成多个物理内存碎片，还有部分暂时存储在外部磁盘存储器上，在需要时进行数据交换。