MOXA linux-2.6.x / linux-2.6.9-uc0 from sdlinux-moxaart.tgz
[linux-2.6.9-moxart.git] / include / linux / ext3_fs_i.h
blob48baa3f4b04d6671046d7935f37519a4dfe98af6
1 /*
2 * linux/include/linux/ext3_fs_i.h
4 * Copyright (C) 1992, 1993, 1994, 1995
5 * Remy Card (card@masi.ibp.fr)
6 * Laboratoire MASI - Institut Blaise Pascal
7 * Universite Pierre et Marie Curie (Paris VI)
9 * from
11 * linux/include/linux/minix_fs_i.h
13 * Copyright (C) 1991, 1992 Linus Torvalds
16 #ifndef _LINUX_EXT3_FS_I
17 #define _LINUX_EXT3_FS_I
19 #include <linux/rwsem.h>
22 * second extended file system inode data in memory
24 struct ext3_inode_info {
25 __le32 i_data[15]; /* unconverted */
26 __u32 i_flags;
27 #ifdef EXT3_FRAGMENTS
28 __u32 i_faddr;
29 __u8 i_frag_no;
30 __u8 i_frag_size;
31 #endif
32 __u32 i_file_acl;
33 __u32 i_dir_acl;
34 __u32 i_dtime;
37 * i_block_group is the number of the block group which contains
38 * this file's inode. Constant across the lifetime of the inode,
39 * it is ued for making block allocation decisions - we try to
40 * place a file's data blocks near its inode block, and new inodes
41 * near to their parent directory's inode.
43 __u32 i_block_group;
44 __u32 i_state; /* Dynamic state flags for ext3 */
47 * i_next_alloc_block is the logical (file-relative) number of the
48 * most-recently-allocated block in this file. Yes, it is misnamed.
49 * We use this for detecting linearly ascending allocation requests.
51 __u32 i_next_alloc_block;
54 * i_next_alloc_goal is the *physical* companion to i_next_alloc_block.
55 * it the the physical block number of the block which was most-recently
56 * allocated to this file. This give us the goal (target) for the next
57 * allocation when we detect linearly ascending requests.
59 __u32 i_next_alloc_goal;
60 #ifdef EXT3_PREALLOCATE
61 __u32 i_prealloc_block;
62 __u32 i_prealloc_count;
63 #endif
64 __u32 i_dir_start_lookup;
65 #ifdef CONFIG_EXT3_FS_XATTR
67 * Extended attributes can be read independently of the main file
68 * data. Taking i_sem even when reading would cause contention
69 * between readers of EAs and writers of regular file data, so
70 * instead we synchronize on xattr_sem when reading or changing
71 * EAs.
73 struct rw_semaphore xattr_sem;
74 #endif
75 #ifdef CONFIG_EXT3_FS_POSIX_ACL
76 struct posix_acl *i_acl;
77 struct posix_acl *i_default_acl;
78 #endif
80 struct list_head i_orphan; /* unlinked but open inodes */
83 * i_disksize keeps track of what the inode size is ON DISK, not
84 * in memory. During truncate, i_size is set to the new size by
85 * the VFS prior to calling ext3_truncate(), but the filesystem won't
86 * set i_disksize to 0 until the truncate is actually under way.
88 * The intent is that i_disksize always represents the blocks which
89 * are used by this file. This allows recovery to restart truncate
90 * on orphans if we crash during truncate. We actually write i_disksize
91 * into the on-disk inode when writing inodes out, instead of i_size.
93 * The only time when i_disksize and i_size may be different is when
94 * a truncate is in progress. The only things which change i_disksize
95 * are ext3_get_block (growth) and ext3_truncate (shrinkth).
97 loff_t i_disksize;
100 * truncate_sem is for serialising ext3_truncate() against
101 * ext3_getblock(). In the 2.4 ext2 design, great chunks of inode's
102 * data tree are chopped off during truncate. We can't do that in
103 * ext3 because whenever we perform intermediate commits during
104 * truncate, the inode and all the metadata blocks *must* be in a
105 * consistent state which allows truncation of the orphans to restart
106 * during recovery. Hence we must fix the get_block-vs-truncate race
107 * by other means, so we have truncate_sem.
109 struct semaphore truncate_sem;
110 struct inode vfs_inode;
113 #endif /* _LINUX_EXT3_FS_I */