Date: Mon, 31 Oct 2005 16:17:47 +0100 (CET) From: Ivan Voras <ivoras@fer.hr> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-fs@freebsd.org Subject: Re: ext2 large_file Message-ID: <20051031160354.G67271@geri.cc.fer.hr> In-Reply-To: <20051031191139.J38757@delplex.bde.org> References: <20051030183340.B19470@geri.cc.fer.hr> <46D894BD-16E0-4CBA-B40A-EEBAAC2547D2@classicalguitar.net> <20051031191139.J38757@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051031160354.G67271>