inode

挂载硬件设备和磁盘容量配额

巧了我就是萌 提交于 2019-11-30 23:13:13
磁盘容量配额   Linux系统的设计初衷就是让许多人一起使用并执行各自的任务,从而成为多用户、多任务的操作系统。但是,硬件资源是固定且有限的,如果某些用户不断地在Linux系统上创建文件或者存放电影,硬盘空间总有一天会被占满。针对这种情况,root管理员就需要使用磁盘容量配额服务来限制某位用户或某个用户组针对特定文件夹可以使用的最大硬盘空间或最大文件个数,一旦达到这个最大值就不再允许继续使用。可以使用quota命令进行磁盘容量配额管理,从而限制用户的硬盘可用容量或所能创建的最大文件个数。quota命令还有软限制和硬限制的功能。   软限制:当达到软限制时会提示用户,但仍允许用户在限定的额度内继续使用。   硬限制:当达到硬限制时会提示用户,且强制终止用户的操作。 RHEL 7系统中已经安装了quota磁盘容量配额服务程序包,但存储设备却默认没有开启对quota的支持,此时需要手动编辑配置文件,让RHEL 7系统中的/boot目录能够支持quota磁盘配额技术。 编辑/etc/fstab文件,添加参数让存储设备支持磁盘配额技术。早期文件系统添加的参数为usrquota参数,而xfs文件系统使用的是uquota或usrquota   vim /etc/fstab   ...   UUID=9d5e3b22-75ac-4f47-9e2b-dd33a06b0f81 /boot xfs

Linux文件系统及属性

爱⌒轻易说出口 提交于 2019-11-30 15:27:34
Linux 文件系统及属性 宗旨:技术的学习是有限的,分享的精神是无限的。 一、 Linux 系统下文件类型及属性 1 、 inode 结构 /*索引节点对象由inode结构体表示,定义文件在linux/fs.h中*/ struct inode { struct hlist_node i_hash; /* 哈希表 */ struct list_head i_list; /* 索引节点链表 */ struct list_head i_dentry; /* 目录项链表 */ unsigned long i_ino; /* 节点号 */ atomic_t i_count; /* 引用记数 */ umode_t i_mode; /* 访问权限控制 */ unsigned int i_nlink; /* 硬链接数 */ uid_t i_uid; /* 使用者id */ gid_t i_gid; /* 使用者id组 */ kdev_t i_rdev; /* 实设备标识符 */ loff_t i_size; /* 以字节为单位的文件大小 */ struct timespec i_atime; /* 最后访问时间 */ struct timespec i_mtime; /* 最后修改(modify)时间 */ struct timespec i_ctime; /* 最后改变(change)时间 *

How to efficiently monitor a directory for changes on linux?

旧时模样 提交于 2019-11-30 14:04:06
I am working with Magento, and there is a function that merges CSS and Javascript into one big file. Regardless the pros and cons of that, there is the following problem: The final file gets cached at multiple levels that include but are not limited to: Amazon CloudFront Proxy servers Clients browser cache Magento uses an MD5 sum of the concatenated css filenames to generate a new filename for the merged css file. So that every page that has a distinct set of css files gets a proper merged css file. To work around the caching issue, I also included the file modification timestamps into that

一分钟了解Linux文件系统

偶尔善良 提交于 2019-11-30 12:57:08
Linux文件系统原理 在所有的操作系统中文件都有文件名与数据,在Linux系统上文件系统分成两个部分:用户数据 (user data) 与元数据 (metadata)。用户数据,即文件数据块 (data block),数据块是记录文件真实内容的地方;而元数据则是文件的附加属性,如文件大小、创建时间、所有者等信息;在Linux系统中,元数据中的inode号(inode是文件元数据的一部分但其并不包含文件名,inode号即索引节点号)才是文件的唯一标识而非文件名。文件名仅是为了方便人们的记忆和使用,系统或程序通过inode号寻找正确的文件数据块。 Linux文件系统目录 大多数Linux版本采用了FHS(英文:Filesystem Hierarchy Standard 中文:文件系统层次结构标准),FHS定义了系统中每个区域的用途、所需要的最小构成的文件和目录同时还给出了例外处理与矛盾处理。对于ext2/3/4的文件系统,默认的data block大小是4096 byte,当需要新建文件或者目录的时候,最小的分配单位就是data block,也就是4K大小,比如一个文件内容是4M,就要分配1000个data block来存放这个文件的内容,而文件或者目录的属性、权限、data block编号是存在对应的inode中。当新建一个目录的时候,会默认的分配一个block

Can inode and crtime be used as a unique file identifier?

前提是你 提交于 2019-11-30 11:33:32
I have a file indexing database on Linux . Currently I use file path as an identifier. But if a file is moved/renamed, its path is changed and I cannot match my DB record to the new file and have to delete/recreate the record. Even worse, if a directory is moved/renamed, then I have to delete/recreate records for all files and nested directories. I would like to use inode number as a unique file identifier, but inode number can be reused if file is deleted and another file created. So, I wonder whether I can use a pair of {inode,crtime} as a unique file identifier. I hope to use i_crtime on

linux 文件系统之 inode 和 block

烈酒焚心 提交于 2019-11-30 10:43:47
linux 文件系统之 inode 和 block inode 和 block 1>含义: index node 索引节点 用来存放文件属性的空间,通过inode 号码来找到这个空间 inode号码----家庭地址 inode空间----家房子 2>怎么来的 格式化创建文件系统时来的 3>特点: 1。inode 是存放文件属性 2.我们每创建一个文件占用一个inode(一般256字节) block 1》含义 数据块 实际存放数据的空间 2>怎么来的 格式化创建文件系统时来的 3》特点 1.block实际存放数据的空间 2.block 一般是4k(还有 1k,8k centos 默认4k) 3.一般大文件会占用多个block,如果文件很小,4k中剩余的空间会被浪费 4.在Linux中创建一个文件,会占用一个 inode和只是一个block 一般我们系统中,block用的比较快, 磁盘空间不足故障:no space left on device 来源: https://blog.csdn.net/tlkj6868xds/article/details/101296633

Flume-Taildir Source 监控目录下多个文件的追加

梦想的初衷 提交于 2019-11-30 06:31:24
Exec source 适用于监控一个实时追加的文件,但不能保证数据不丢失;Spooldir Source 能够保证数据不丢失,且能够实现断点续传,但延迟较高,不能实时监控;而 Taildir Source 既能够实现断点续传,又可以保证数据不丢失,还能够进行实时监控。 一、创建配置文件 flume-taildir-hdfs.conf https://flume.apache.org/FlumeUserGuide.html#taildir-source 监控 /tmp/upload/ 目录下以 COMPLETED 结尾的文件 a3.sources = r3 a3.sinks = k3 a3.channels = c3 # Describe/configure the source a3.sources.r3.type = TAILDIR a3.sources.r3.filegroups = f1 a3.sources.r3.filegroups.f1 = /tmp/upload/.*COMPLETED a3.sources.r3.positionFile = /opt/apache-flume-1.9.0-bin/tail_dir.json # Describe the sink a3.sinks.k3.type = hdfs a3.sinks.k3.hdfs.path =

【转帖】Linux 内核系统架构

孤街浪徒 提交于 2019-11-30 06:21:18
Linux 内核系统架构 描述Linux内核的文章已经有上亿字了 但是对于初学者,还是应该多学习多看,毕竟上亿字不能一下子就明白的。 即使看了所有的Linux 内核文章,估计也还不是很明白,这时候,还是需要fucking the code. 28年前(1991年8月26日)Linus公开Linux的代码,开启了一个伟大的时代。这篇文章从进程调度,内存管理,设备驱动,文件系统,网络等方面讲解Linux内核系统架构。Linux的系统架构是一个经典的设计,它优秀的分层和模块化,融合了数量繁多的设备和不同的物理架构,让世界各地的内核开发者能够高效并行工作。先来看看Linus在多年前公开Linux的邮件。 "Hello everybody out there using minix - I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I’d like any feedback on things people like/dislike in minix, as my OS

[Bachelor] 磁盘与文件系统

╄→гoц情女王★ 提交于 2019-11-30 03:20:57
目录 文件系统概述 1. 磁盘分区 1.1 磁盘装置名 1.2 MSDOS(MBR) 与 GPT 磁盘分区表(partition table) 1.3 挂载 2. Linux文件系统 2.1 文件系统的概念 2.2 Linux 的 EXT2 文件系统 2.3 文件的存取与日志式文件系统的功能 2.4 Linux 文件系统的运作 文件系统概述 参考自《鸟哥的Linux私房菜》:http://linux.vbird.org/ 1. 磁盘分区 1.1 磁盘装置名 磁盘文件名:实体磁盘大多使用 /dev/sd[a-] 这样的文件名,而虚拟机下的虚拟磁盘可能会使用 /dev/vd[a-p] 这种文件名。 所有使用SCSI模块驱动的磁盘接口的装置文件名都是 /dev/sd[a-p] 的格式。顺序则由磁盘被系统侦测到的顺序决定。 磁盘可能有多个磁盘盘,所有磁盘盘上的同一个磁道组成的同心圆称为磁柱。 1.2 MSDOS(MBR) 与 GPT 磁盘分区表(partition table) MSDOS(MBR)分区表格式 在第一个扇区 512bytes 会有如下数据: 主要启动记录区(Master Boot Record, MBR):安装开机管理程序的地方,446 bytes 分区表(partition table):记录整个硬盘分区的状态,46 bytes 分区表最多只能有四组记录区

一种以动态库的方式使用资源表的方案

喜夏-厌秋 提交于 2019-11-30 02:17:37
这段时间研究了一下资源表的优化方案,算是有了一些成果,在此记录下来。 先交代一下背景吧:我们的服务器把资源表放在共享内存上。这么做的原因主要是,进程core掉后再拉起时不需要重新再构建一遍资源表(构建资源表主要就是构建索引查询的数据结构,比如构建一个哈希表用于根据HeroID查询英雄配置这种)。然后,考虑到同一个机器上可能部署多个进程,于是自然就想到,能否有一种机制能够让一个机器上的多个进程共享同一块资源表的内存? 一个比较直观的想法就是,让多个进程挂在同一块资源表共享内存。这样做确实是可以达到内存共享的目的,但是需要考虑资源表reload的情况。reload时会对这块内存做写操作,而我们知道,一写多读是会有并发问题。因此这种方案还需要再引入一种机制来处理并发问题。常见的比如是双缓冲区,构建好后再一次性切换到新的资源表内存上。了解到了一些项目组确实也是这么做的,具体就不细说了。 而我想到的方法是这样的:使用代码生成技术,将资源表完全的导成c++的代码。所有用到于查询的数据结构都是通过自动代码生成的,并且在编译期就被静态构建好了。进程运行时直接载入这块内存即可,不需要像以前那样在起服时跑资源表构建的流程。因此,这块内存也不需要再手动放共享内存上了。core之后再拉起进程,最多就是资源表的内存被卸载了,并且会到下次用到时通过触发缺页中断被再次载入进内存。为了做同一机器上的内存共享