乐橙a2x用硬盘存储

1. 乐橙TP7-AD2C支持onvif协议吗

可以的，支持ONVIF协议，可以接入第三方硬盘录像机，支持SD卡、云存储、硬盘录像机三种存储方式，满意请采纳并点赞噢

2. 乐橙摄像头怎么格式化内存卡

方法如下：
1、将内存卡插入读卡器内，并插上主机的USB插口，等会就会在出现可移动磁盘。
2、然后打开“我的电脑”或“计算机”就可以看到读卡器的磁盘了——那就是内存卡，右键单击那个磁盘在弹出的右键菜单中选“格式化”之后会弹出一个窗口，在其中勾选上“快速格式化”后点开始就可以了。
(2)乐橙a2x用硬盘存储扩展阅读：
储存卡格式化：储存卡格式化（FORMAT）是指对其初始化工作。格式化是电子产品对相配套存储介质的一种空间分配，在分配的同时，也起到了数据保护功能。格式化之后，会占用一定的空间，可以理解为是一个个格子所占用的空间。
详细介绍
储存卡格式化就是对其初始化工作，同其他存储器硬盘、磁盘一样必须格式化才能使用。格式化就是为磁盘做初始化的工作，简单说，就是把一张空白的盘划分成一个个小区域并编号，供计算机储存，读取数据。格式化这一概念原只应用于电脑硬盘，随着电子产品不断发展，很多存储器都用到了“格式化”这一名词，狭义的理解，就等于数据清零，删掉存储器内的所有数据，并将存储器恢复到初始状态。
硬盘必须先经过分区才能使用，磁盘经过分区之后，下一个步骤就是要对硬盘进行高级格式化（FORMAT）的工作，硬盘都必须格式化才能使用。
对手机卡的格式化可以选择在插入读卡器，在电脑上格式化，也可以在插入手机里，用手机里的程序进行格式化。对于这两种方法，一般选择后者较好，因为可以保证格式化后的文件系统可以被手机正常识别。格式化之后，会占用一定的空间，可以理解为是一个个格子所占用的空间。例如1G的MP3只有800多MB。
格式化是电子产品对相配套存储介质的一种空间分配，在分配的同时，也起到了数据保护功能。格式化也有很多种形式，根据格式后每个空间的大小大致可以分为，低格，高格。低格后的储存卡容量相对较大，但存储速度较慢，高格后的存储空间减少的多一些，速度快，同时安全性要高。

3. 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.

4. 乐橙监控是否后台能储存

你好，乐橙监控后台是可以储存的。
因为监控设备当中手机回看的内容，是使用硬盘的储存系统进行查看的，一般来说，监控的内容都会被记录到内存卡的优盘当中，手机则是能够在存储卡当中进行查看。
以1TB的硬盘绑定4个乐橙TP7的录制时间为例，一个摄像头的使用天数=总硬盘的存储大小÷每个摄像头每天所需要的存储大小。
一个硬盘的大小是1TB,1TB=1024GB，所以一个摄像头的使用天数就是1×1024 ÷10.546875≈97天。

5. 乐橙硬盘录像机后面A/B是什么插座

有的硬盘录像机后面标有A/B的接线端子一般是485接线端子，目的是为了控制带云台的摄像机，A是表示接485+，B是接485—。
乐橙硬盘录像机是一款定位于个人私有数据备份、共享和存储的家用网络存储设备，乐橙硬盘录像机提供基于Android操作系统的TB级存储能力，支持4K高清HDMI视频输出、Hi-F（High-Fidelity）级音效输出、手机端APP远程管理及数据访问、查看及远程下载录像和图片等功能。设备连接远程IPC后，可实现实时监视、录像回放、报警事件推送等，为家庭安全提供全方位保障。

6. 乐橙A22E怎么内存卡保存的视频就几分钟

乐橙A22E怎么内存卡保存的视频保持时间短是因为内存太小
存储大小指的是你购买的硬盘录像机或者是SD卡的内存大小。硬盘录像机，一般最大能放8块硬盘，若是一个硬盘容量是1TB，这样硬盘录像机的容量就是8TB，1TB=1024GB，也就是有8192GB的容量；SD卡平时很常见，有64GB、128GB、256GB等等内存大小。

7. 乐橙监控,手机回看是通过硬盘的存储吗

你好！监控设备手机回看的内容，是通过硬盘的储存系统查看的，通常监控内容都会录入储存在内存卡优盘里边，手机可以从存储卡里边查看。

8. 乐橙录像机买的时候没有硬盘,可以自己装个硬盘吗

以在没有硬盘的情况下设置的，我确定
你调试的时候接个屏就能看了，把参数设置好保存就行。用的时候再装上硬盘
还有，很不懂你说“想要无硬盘的状况下设置好。怕坏了”-----机器不会
你接的摄像头控制点多不？不多的话可以直接接显示来看啦~
不过既然你已经有硬盘录像机就可以直接接显示器（监视器）看啦，一般都可以支持的呢~因为他是分两路，一路直接给显示器，一路直接录像，而且你可以分别设置显示码流和存储码流~
不会坏的啦！
放心！不需要。如果有远程监控需求的话，要安装客户端软件（硬盘录像机带该软件），在局域网内也可以通过ie浏览器直接登录硬盘录像机的ip地址实现行程监控。
乐橙怎么连硬盘录像机。部分型号的乐橙是不支持连接硬盘录像机（NVR）的，请仔细核对自己的乐橙是否支持！
工具/原料
more
无线路由器，网线，大华硬盘录像机（NVR）
方法/步骤
1/4分步阅读
安装一个路由器，并发射出足够强的WIFI信号覆盖到摄像头安装处。（如果需要远程查看，就将路由器接入外网即可，其他操作不变）

2/4
用网线连接路由器和硬盘录像机，路由器和硬盘录像机上都是连接LAN口。

3/4
乐橙再连接路由器发射出来的WIFI信号。

4/4
现在就可以在硬盘录像机上检索摄像头了。如果不能自动激活或是添加不上，就需要手机也连接上WIFI，手动激活配置好乐橙，然后再到硬盘录像机上手动添加乐橙到硬盘录像机上。

注意事项
部分型号的乐橙是不支持连接硬盘录像机的，请核对自己的乐橙型号。

9. 乐橙不开通云存储可以用吗

能。
需要的安全级别不高，可以不开通云存储，同时连接硬盘机也不用云空间。
云存储是一种网上在线存储的模式，即把数据存放在通常由第三方托管的多台虚拟服务器，而非专属的服务器上。

10. 乐橙摄像头连接录像机硬盘，储存在那里，是sd卡还是录像机硬盘里！

如果摄像头同时连接录像机还装了SD卡，那么录像机和sd卡都会有存录像，循环周期不同而已，乐橙摄像头不装sd卡，远程会提示无sd卡，也就是看不了录像，但本地录像机上是可以看的。 可能不是所有型号吧，但大多数都是这样。海康的没这种问题，大华的软件没海康的强大，远程延迟太高了，还各种问题。。。