Subversion Repositories shark

Rev

Rev 422 | Details | Compare with Previous | Last modification | View Log | RSS feed

Rev Author Line No. Line
422 giacomo 1
/*
2
 *  linux/include/linux/ext3_fs_i.h
3
 *
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)
8
 *
9
 *  from
10
 *
11
 *  linux/include/linux/minix_fs_i.h
12
 *
13
 *  Copyright (C) 1991, 1992  Linus Torvalds
14
 */
15
 
16
#ifndef _LINUX_EXT3_FS_I
17
#define _LINUX_EXT3_FS_I
18
 
19
#include <linux/rwsem.h>
20
 
21
/*
22
 * second extended file system inode data in memory
23
 */
24
struct ext3_inode_info {
25
        __u32   i_data[15];
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;
35
 
36
        /*
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.
42
         */
43
        __u32   i_block_group;
44
        __u32   i_state;                /* Dynamic state flags for ext3 */
45
 
46
        /*
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.
50
         */
51
        __u32   i_next_alloc_block;
52
 
53
        /*
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.
58
         */
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
66
        /*
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.
72
         */
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
79
 
80
        struct list_head i_orphan;      /* unlinked but open inodes */
81
 
82
        /*
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.
87
         *
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.
92
         *
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).
96
         */
97
        loff_t  i_disksize;
98
 
99
        /*
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.
108
         */
109
        struct semaphore truncate_sem;
110
        struct inode vfs_inode;
111
};
112
 
113
#endif  /* _LINUX_EXT3_FS_I */