kernel-fxtec-pro1x/include/linux/statfs.h

#ifndef _LINUX_STATFS_H
#define _LINUX_STATFS_H

#include <linux/types.h>

#include <asm/statfs.h>

struct kstatfs {
	long f_type;
	long f_bsize;
	u64 f_blocks;
	u64 f_bfree;
	u64 f_bavail;
	u64 f_files;
	u64 f_ffree;
	__kernel_fsid_t f_fsid;
	long f_namelen;
	long f_frsize;
	long f_spare[5];
};

#endif
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip! 2005-04-16 16:20:36 -06:00			`#ifndef _LINUX_STATFS_H`
			`#define _LINUX_STATFS_H`

			`#include <linux/types.h>`

			`#include <asm/statfs.h>`

			`struct kstatfs {`
			`long f_type;`
			`long f_bsize;`
[PATCH] 2TB files: change type of kstatfs entries This fix was proposed by Trond Myklebust. He says: The type "sector_t" is heavily tied in to the block layer interface as an offset/handle to a block, and is subject to a supposedly block-specific configuration option: CONFIG_LBD. Despite this, it is used in struct kstatfs to save a couple of bytes on the stack whenever we call the filesystems' ->statfs(). So kstatfs's entries related to blocks are invalid on statfs64 for a network filesystem which has more than 2^32-1 blocks when CONFIG_LBD is disabled. - struct kstatfs Change the type of following entries from sector_t to u64. f_blocks f_bfree f_bavail f_files f_ffree Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by: Takashi Sato <sho@tnes.nec.co.jp> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> 2006-03-26 02:37:54 -07:00			`u64 f_blocks;`
			`u64 f_bfree;`
			`u64 f_bavail;`
			`u64 f_files;`
			`u64 f_ffree;`
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip! 2005-04-16 16:20:36 -06:00			`__kernel_fsid_t f_fsid;`
			`long f_namelen;`
			`long f_frsize;`
			`long f_spare[5];`
			`};`

			`#endif`