ext2 large_file
Ivan Voras
ivoras at fer.hr
Mon Oct 31 07:24:07 PST 2005
On Mon, 31 Oct 2005, Bruce Evans wrote:
> tjr implemented it in FreeBSD almost 2 years ago:
It doesn't, or something other is wrong. This happens on a freshly created
ext2fs:
> dd if=/dev/zero of=big_file bs=1m count=2500
dd: big_file: File too large
2048+0 records in
2047+0 records out
2146435072 bytes transferred in 100.387067 secs (21381590 bytes/sec)
> l
total 2098180
-rw-r--r-- 1 ivoras wheel 2146435072 Oct 31 16:09 big_file
(btw: the transfer rate is also somewhat bad: 50% of CPU time was taken,
~25% in sys, ~25% in interrupts. This is UP machine. I think this is
because ext2 support seems to divide I/O requests into 4KB chunks :( )
Here's what dumpe2fs says:
Filesystem volume name: walker_ext2
Last mounted on: <not available>
Filesystem UUID: 9a920c62-05f6-4631-8c90-30af2c63d5df
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: filetype sparse_super
Default mount options: bsdgroups
Filesystem state: not clean
Errors behavior: Continue
Filesystem OS type: FreeBSD
Inode count: 4889248
Block count: 9769520
Reserved block count: 488476
Free blocks: 9091534
Free inodes: 4889235
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16352
Inode blocks per group: 511
Filesystem created: Mon Oct 31 15:57:15 2005
Last mount time: n/a
Last write time: Mon Oct 31 16:09:16 2005
Mount count: 0
Maximum mount count: 26
Last checked: Mon Oct 31 15:57:15 2005
Check interval: 15552000 (6 months)
Next check after: Sat Apr 29 16:57:15 2006
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group wheel)
First inode: 11
Inode size: 128
Default directory hash: tea
Directory Hash Seed: 8d6e7f0b-37f2-45bd-8d65-fc515046d7b6
(it's not clean because it's mounted. I've set the bsdgroups option
myself with tune2fs)
> Compatibility flags shouldn't be forced on IMO. Linux does it for this
> flag, but this is a bug IMO. It breaks subsequent remounting r/w on
> old or other kernels that don't support large files.
So, how to set the flag? man pages for tune2fs and mke2fs don't mention
the large_file option. Is there some other utility that does this?
>>> I recently tried to use ext2 on FreeBSD but have decided not to when I saw
>>> that the support for large files is missing (and went with msdosfs
>>> instead).
>
> msdosfs is physically incapable of supporting large files. Its maximum
> file size is the constant 0xffffffff.
Yes, I should have said "larger" files :) Current ext2 support in FreeBSD
is limited to 2GB files, while 4GB is enough for me for now.
> NetBSD got it 9 months ago, only a year after FreeBSD. It refuses to
> create files larger than 2G-1 if the ext2fs rev number is old, and says
> in a comment that Linux silently upgrades the rev number. It silently
> clobbers the compat flag like Linux. Someone has an off-by-power-of-2
> error -- the corresponding limit in FreeBSD is 4G-1.
I just tried it - the limit is 2GB on FreeBSD.
So, it seems that it boils down to that FreeBSD's ext2 support still
cannot handle large files?
More information about the freebsd-fs
mailing list