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