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>
index | next in thread | previous in thread | raw e-mail
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?home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051031160354.G67271>