25 May, 2011
3 commits
-
Patch also manages to add a manipulative struture for this ioctl.
Signed-off-by: Tristan Ye
-
This new code is a bit more complicated than former ones, the goal is to
show user all statistics required to take a deep insight into filesystem
on how the disk is being fragmentaed.The goal is achieved by scaning global bitmap from (cluster)group to group
to figure out following factors in the filesystem:- How many free chunks in a fixed size as user requested.
- How many real free chunks in all size.
- Min/Max/Avg size(in) clusters of free chunks.
- How do free chunks distribute(in size) in terms of a histogram,
just like following:
---------------------------------------------------------
Extent Size Range : Free extents Free Clusters Percent
32K... 64K- : 1 1 0.00%
1M... 2M- : 9 288 0.03%
8M... 16M- : 2 831 0.09%
32M... 64M- : 1 2047 0.23%
128M... 256M- : 1 8191 0.92%
256M... 512M- : 2 21706 2.43%
512M... 1024M- : 27 858623 96.29%
---------------------------------------------------------Userspace ioctl() call eventually gets the above info returned by passing
a 'struct ocfs2_info_freefrag' with the chunk_size being specified first.Signed-off-by: Tristan Ye
-
The new code is dedicated to calculate free inodes number of all inode_allocs,
then return the info to userpace in terms of an array.Specially, flag 'OCFS2_INFO_FL_NON_COHERENT', manipulated by '--cluster-coherent'
from userspace, is now going to be involved. setting the flag on means no cluster
coherency considered, usually, userspace tools choose none-coherency strategy by
default for the sake of performace.Signed-off-by: Tristan Ye
16 Oct, 2010
1 commit
-
…into ocfs2-merge-window
Conflicts:
fs/ocfs2/ocfs2.h
24 Sep, 2010
1 commit
-
We sync our inode flags with ext2 and define them by hex
values. But actually in commit 3669567(4 years ago), all
these values are moved to include/linux/fs.h. So we'd
better also use them as what ext2 did. So sync our inode
flags with ext2 by using FS_*.Signed-off-by: Tao Ma
Signed-off-by: Joel Becker
10 Sep, 2010
1 commit
-
The reason why we need this ioctl is to offer the none-privileged
end-user a possibility to get filesys info gathering.We use OCFS2_IOC_INFO to manipulate the new ioctl, userspace passes a
structure to kernel containing an array of request pointers and request
count, such as,* From userspace:
struct ocfs2_info_blocksize oib = {
.ib_req = {
.ir_magic = OCFS2_INFO_MAGIC,
.ir_code = OCFS2_INFO_BLOCKSIZE,
...
}
...
}struct ocfs2_info_clustersize oic = {
...
}uint64_t reqs[2] = {(unsigned long)&oib,
(unsigned long)&oic};struct ocfs2_info info = {
.oi_requests = reqs,
.oi_count = 2,
}ret = ioctl(fd, OCFS2_IOC_INFO, &info);
* In kernel:
Get the request pointers from *info*, then handle each request one bye one.
Idea here is to make the spearated request small enough to guarantee
a better backward&forward compatibility since a small piece of request
would be less likely to be broken if filesys on raw disk get changed.Currently, the following 7 requests are supported per the requirement from
userspace tool o2info, and I believe it will grow over time:-)OCFS2_INFO_CLUSTERSIZE
OCFS2_INFO_BLOCKSIZE
OCFS2_INFO_MAXSLOTS
OCFS2_INFO_LABEL
OCFS2_INFO_UUID
OCFS2_INFO_FS_FEATURES
OCFS2_INFO_JOURNAL_SIZEThis ioctl is only specific to OCFS2.
Signed-off-by: Tristan Ye
Signed-off-by: Joel Becker
03 Mar, 2010
1 commit
-
Currently we were adding ioctl cmds/structures for ocfs2 into ocfs2_fs.h
which was used for define ocfs2 on-disk layout. That sounds a little bit
confusing, and it may be quickly polluted espcially when growing the
ocfs2_info_request ioctls afterwards(it will grow i bet).As a result, such OCFS2 IOCs do need to be placed somewhere other than
ocfs2_fs.h, a separated ocfs2_ioctl.h will be added to store such ioctl
structures and definitions which could also be used from userspace to
invoke ioctls call.Signed-off-by: Tristan Ye
Signed-off-by: Joel Becker