2008-03-05 21:21:50 statfs the harddisk too long for the first running..
Wei Jiang (CHINA)
Message: 52135
Dear all,
I have a question about the "statfs" and the harddisk.
After I mounted my hard-disk, it use too long time to "statfs" the harddisk for the first time. Just below:
root:/tmp> time ./sts
type:0x0000ef53, block size:1024
Command exited with non-zero status 33
real 0m 0.00s
user 0m 0.00s
sys 0m 0.00s
root:/tmp> mount /dev/hda /mnt/hda0/
root:/tmp> time ./sts
type:0x00004d44, block size:16384
Command exited with non-zero status 34
real 0m 28.11s //********************************Too long here, must be something wrong.
user 0m 0.00s
sys 0m 12.78s
root:/tmp> time ./sts
type:0x00004d44, block size:16384
Command exited with non-zero status 34
real 0m 0.00s
user 0m 0.00s
sys 0m 0.00s
root:/tmp
And this is my "sts":
struct statfs lfs;
statfs("/mnt/hda0", &lfs);
#ifdef __USE_FILE_OFFSET64
printf("bbbbbbb\n");
#endif
printf("type:0x%.8x, block size:%d\n", lfs.f_type, lfs.f_bsize);
There must be something wrong but I can't find it. Please give me some advices.
Thank you!
QuoteReplyEditDelete
2008-03-06 00:37:22 Re: statfs the harddisk too long for the first running..
Mike Frysinger (UNITED STATES)
Message: 52137 you're barking up the wrong tree ... if statfs() is "taking too long", it means the kernel is getting hung up which means your IDE driver is most likely flaking out
look in `dmesg` for information
you also didnt say what kernel/toolchain version you're using, or what hardware platform and IDE device driver
QuoteReplyEditDelete
2008-03-06 01:15:11 Re: statfs the harddisk too long for the first running..
Wei Jiang (CHINA)
Message: 52140
Hi, Mike,
Thanks a lot for your help.
Here is my "dmesg":
inux version 2.6.22.14 (xx@xx-desktop) (gcc version 4.1.2 (ADI svn)) #62 Thu Mar 6 10:05:40 CST 2008
Hardware Trace Active and Enabled
Compiled for ADSP-BF561 Rev 0.5 / 0.5
Speed: 599 MHz CCLK and 119 MHz SCLK
Memory map: 32 / 64 MB
text = 0x00001000-0x00132fc0
rodata = 0x00133000-0x0018e534
data = 0x0018f000-0x001ba000
stack = 0x00190000-0x00192000
init = 0x001ba000-0x001d3000
bss = 0x001d3000-0x001e9630
available = 0x001e9630-0x01600000
rootfs = 0x01600000-0x01e00000
DMA Zone = 0x01e00000-0x02000000
Instruction Cache Enabled
Data Cache Enabled (write-through)
Built 1 zonelists. Total pages: 5588
Kernel command line: console=ttyBF0,115200n8 root=0x1f00 rw mem=32m max_mem=64m
Configuring Blackfin Priority Driven Interrupts
PID hash table entries: 128 (order: 7, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Physical pages: 1600
Memory available: 8192k romfs + 20272k/31172k RAM
(100k init code, 1223k kernel code, 89k data, 2048k dma)
Scratchpad data SRAM: 4 KB
Data A SRAM: 16 KB (15 KB free)
Data B SRAM: 16 KB (16 KB free)
Instruction SRAM: 16 KB (8 KB free)
Security Framework v1.0.0 initialized
Mount-cache hash table entries: 512
NET: Registered protocol family 16
Blackfin GPIO Controller
Blackfin DMA Controller
blackfin_init(): registering device resources
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP reno registered
BF-COREB Proc-FS: v0.2.0
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler cfq registered
PPI: PPI-EKC Driver INIT IRQ:23
bfin-wdt: initialized timeout=20s (nowayout=0)
bfin-uart.1: ttyBF0 at MMIO 0xffc00400 (irq = 35) is a BFIN-UART
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
dm9000 Ethernet Driver
eth0: dm9000 at 2c000000,2c000004 IRQ 83 MAC: 04:01:7c:00:ca:44
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
ide0: Blackfin generic IDE interface
hda: ST3250820SV, ATA DISK drive
ide0 at 0x28000040-0x28000047,0x28000038 on irq 120
hda: max request size: 512KiB
hda: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63
hda: cache flushes supported
hda: hda1
uclinux[mtd]: RAM probe address=0x1600000 size=0x800000
Creating 1 MTD partitions on "RAM":
0x00000000-0x00800000 : "EXT2fs"
And my kernel is 2.6.22.4, bfin-uclinux-gcc is 4.1.2(newest svn). Hardware: BF561.
the same program(with same toolchains) runs OK on the 2.6.18 or newest kernel..
QuoteReplyEditDelete
2008-03-06 01:35:50 Re: statfs the harddisk too long for the first running..
Wei Jiang (CHINA)
Message: 52141
OK, plz see here;
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/133567...
QuoteReplyEditDelete
2008-03-06 02:08:52 Re: statfs the harddisk too long for the first running..
Mike Frysinger (UNITED STATES)
Message: 52142 so it's a bug in the fat filesystem ... and if you try the fix merged upstream ?
QuoteReplyEditDelete
2008-03-06 02:48:07 Re: statfs the harddisk too long for the first running..
Wei Jiang (CHINA)
Message: 52144
Mike,
I accepted this patch but it seems no effect . I'm really puzzled now...
time ./sts
type:0x00004d44, block size:16384
Command exited with non-zero status 34
real 0m 44.08s
user 0m 0.00s
sys 0m 10.84s
It's much more big. That's funny...
QuoteReplyEditDelete
2008-03-10 16:37:58 Re: statfs the harddisk too long for the first running..
Mike Frysinger (UNITED STATES)
Message: 52283 mount it with the 'usefree' option:
mount -o usefree ...
QuoteReplyEditDelete
2008-03-10 21:45:22 Re: statfs the harddisk too long for the first running..
Wei Jiang (CHINA)
Message: 52298 Thank you, Mike..
I used to read the man infomation on my feisty ubuntu but it has no this option.
It's my fault, Now It works. Thanks again..
QuoteReplyEditDelete
2008-03-10 22:48:31 Re: statfs the harddisk too long for the first running..
Mike Frysinger (UNITED STATES)
Message: 52301 the man pages havent been updated to document this option ... read linux-2.6.x/Documentation/filesystems/vfat.txt before you go using the option so that you know why it takes a long time the first time and what the option is actually doing
then you can make an educated choice as to whether take the delay penalty the first time or rely on the header being correct ...