A specific example of a disk i/o problem (was: FreeBSD vs Ubuntu)
|
View:
New views
15 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: A specific example of a disk i/o problem (was: FreeBSD vs Ubuntu)
by Attilio Rao-2
::
Rate this Message:
2009/9/30 Dieter <freebsd@...>:
>> > My question is why is FreeBSD's disk i/o performance so bad? >> >> As I mentioned... this was discussed actively in slashdot. You will find >> there many good comments on this. > > All I saw in slashdot was a ffs vs ext comment. I don't believe the problems > I'm seeing are filesystem related. > >> > Not just in the benchmarks with debugging on, but in real world usage >> > where it actually matters. >> >> Are you saying this from actual experience or from reading other people's >> comments? > > Here is a specific demo of one disk i/o problem I'm seeing. Should be > easy to reproduce? > > http://lists.freebsd.org/pipermail/freebsd-performance/2008-July/003533.html > > This was over a year ago, so add 7.1 to the list of versions with the problem. > I believe that the > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1148109, size: 4096 > messages I'm getting are the same problem. A user process is hogging > the bottleneck (disk buffer cache?) and the swapper/pager is getting starved. Sorry, do you have a PR/describing e-mail with this issue? Can you be a bit more precise? The problem reported in the earlier post, however, is interesting and worths more analysis. More speficially, would you be interested in reproducing and playing a bit with some diagnostic tool/configurations I can point you at? Attilio -- Peace can only be achieved by understanding - A. Einstein _______________________________________________ freebsd-performance@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@..." |
|
|
Re: A specific example of a disk i/o problem
by dieter-7
::
Rate this Message:
> >> > My question is why is FreeBSD's disk i/o performance so bad?
> > Here is a specific demo of one disk i/o problem I'm seeing. Should be > > easy to reproduce? > > > > http://lists.freebsd.org/pipermail/freebsd-performance/2008-July/003533.html > > > > This was over a year ago, so add 7.1 to the list of versions with the problem. > > I believe that the > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1148109, size: 4096 > > messages I'm getting are the same problem. A user process is hogging > > the bottleneck (disk buffer cache?) and the swapper/pager is getting starved. > > Sorry, do you have a PR/describing e-mail with this issue? Can you be > a bit more precise? I have not submitted a PR for this particular problem. (yet) The hardware seems to work fine. A single process can access a disk at full speed, over 100 MB/s for recent 7200 rpm SATA drives. Same for the nforce4-ultra (chipset), JMB363 (PCIe card), or SiI 3132 (PCIe card) controllers. Same for Hitachi, Seagate, Samsung, or WD drives. CPU bound processes play well together. The problem is when I run a disk i/o bound process like cat, dd, etc. The i/o bound process sucks up some resource and other processes get starved for disk i/o not just for milliseconds, but for seconds, even minutes. The example in .../2008-July/003533.html uses a single disk, but the problem also occurs across disks and across controllers. Coming up with a demo using multiple disks that would be easy for someone else to duplicate is more difficult, which is why the demo uses a single disk. It happens with both reading and writing. I don't think it has anything to do with the filesystem (FFS with softdeps). It doesn't matter which process starts first. Given the behaviour, the bottleneck must be something that is common to all the disks, such as the disk cache. The BSD kernel has changed significantly since I took the internals class, so my understanding of the internals is somewhat obsolete. But my best guess is that the bottleneck is some kernel disk cache or disk job queue that the i/o bound job fills up and keeps filled up, and other processes rarely get a chance to get their i/o requests in. Nice, even idprio, has little if any effect. On the machines that Unix grew up on (PDP11, VAX) the CPU was nearly always the scarce resource, so the scheduler doesn't penalize a process for using lots of i/o. This is a serious problem on current hardware. There is no way to keep one process's i/o from interferring with another process. > The problem reported in the earlier post, however, is interesting and > worths more analysis. Can anyone reproduce it? > More speficially, would you be interested in reproducing and playing a > bit with some diagnostic tool/configurations I can point you at? I would welcome info on diagnosing/config/tuning/etc. _______________________________________________ freebsd-performance@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@..." |
|
|
Re: A specific example of a disk i/o problem
by Bill Moran-2
::
Rate this Message:
In response to Dieter <freebsd@...>:
> > >> > My question is why is FreeBSD's disk i/o performance so bad? > > > > Here is a specific demo of one disk i/o problem I'm seeing. Should be > > > easy to reproduce? > > > > > > http://lists.freebsd.org/pipermail/freebsd-performance/2008-July/003533.html FYI, I thought I'd play around with this some in an attempt to add some useful information to the investigation. I can not reproduce the problem at all. I created a 9G file, did the cat as described in the above URL, and the man request completed in roughly the same time it did without the cat running. Just to mix it up a bit, I tried running ls -R on a large directory tree while the cat was running as well, and performance did not seem to be significantly impacted there, either. I ran the tests on my work machine, which is a Dell Optiplex 960 running FreeBSD 7.2-RELEASE-p3 i386. Some relevant dmesg stuff: atapci0: <Intel ATA controller> port 0xfe80-0xfe87,0xfe90-0xfe93,0xfea0-0xfea7,0xfeb0-0xfeb3,0xfef0-0xfeff irq 18 at device 3.2 on pci0 atapci1: <Intel ICH8 SATA300 controller> port 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfec0-0xfedf mem 0xff970000-0xff9707ff irq 18 at device 31.2 on pci0 ad14: 476940MB <Seagate ST3500630AS 3.AAK> at ata7-master SATA150 -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ _______________________________________________ freebsd-performance@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@..." |
|
|
Re: A specific example of a disk i/o problem
by dieter-7
::
Rate this Message:
> > > >> > My question is why is FreeBSD's disk i/o performance so bad?
> > > > > > Here is a specific demo of one disk i/o problem I'm seeing. Should be > > > > easy to reproduce? > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-performance/2008-July/003533.html > > FYI, I thought I'd play around with this some in an attempt to add some > useful information to the investigation. > > I can not reproduce the problem at all. I created a 9G file, did the cat > as described in the above URL, and the man request completed in roughly > the same time it did without the cat running. How large is main memory on this machine? e.g. is 9 GB large enough to flush everything else out of the disk cache before running the man command again? I haven't studied the new unified memory thing, but if we assume worst case, reading at 50 M/s would take 40 seconds to flush 2 GiB. BTW there is nothing magic about a 9 GB file, just that it is large enough to flush the 2 GiB of main memory on my machine and takes long enough to read to notice a difference in how long it takes to run man. Updated demo, just to make sure: # big_file is larger than main memory, on same disk as man (/usr) time man de # get baseline time for man command without competing i/o cat big_file > /dev/null # flush man command and data from memory cat big_file > /dev/null & # generate i/o, attempt to use up bottleneck time man de # see how much longer man takes with competing i/o _______________________________________________ freebsd-performance@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@..." |
|
|
|
|
|
|
|
|
|
|
|
ZFS Re: A specific example of a disk i/o problem
by dieter-7
::
Rate this Message:
In message <E316139E-FFCF-432F-8DCE-62B120C38E55@...>, Thomas Backman writes:
> I run 8.0-RC1/amd64 with ZFS on an A64 3200+ with 2GB RAM and an old > 80GB 7200rpm disk. > > My problem is that I get completely unacceptable latency on console IO > (both via SSH and serial console) when the system is performing disk > IO. The worst case I've noticed yet was when I tried copying a core > dump from a lzjb compressed ZFS file system to a gzip-9 compressed > one, to compare the file size/compression ratio. screen(1) took at > LEAST ten seconds - probably a bit more - I'm not exaggerating here - > to switch to another window, and an "ls" in an empty directory also > about 5-10 seconds. You might find the "RELENG_7 heavy disk = system crawls" thread interesting: } I didn't actually solve it or do anything. } I just upgraded to RELENG_8. } } Now it's behaving more like FreeBSD should. } I can do sequential reads/writes and still } use kbd/mouse/X11/buildworld and so on. _______________________________________________ freebsd-performance@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@..." |
|
|
tuning FFS for large files Re: A specific example of a disk i/o problem
by dieter-7
::
Rate this Message:
I found a clue! The problem occurs with my big data partitions,
which are newfs-ed with options intended to improve things. Reading a large file from the normal ad4s5b partition only delays other commands slightly, as expected. Reading a large file from the tuned ad4s11 partition yields the delay of minutes for other i/o. # tunefs -p /dev/ad4s5b tunefs: ACLs: (-a) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: gjournal: (-J) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 1024 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) # tunefs -p /dev/ad4s11 tunefs: ACLs: (-a) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: gjournal: (-J) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 57984 tunefs: average file size: (-f) 67108864 tunefs: average number of files in a directory: (-s) 16 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) Here is the newfs command used for creating large data partitions: newfs -e 57984 -b 65536 -f 8192 -g 67108864 -h 16 -i 67108864 -U -o time $partition Even this isn't tuned the way I wanted to. -g * -h must be less than 4 G due to 32 bit problem (system panics). Note the 32 bit problem is in the filesystem code, I'm running amd64. IIRC there is a PR about this. (I'm assuming the bug hasn't been fixed yet) Result is that I must specify -g and -h smaller than they should be. And they have way more inodes than needed. (IIRC it doesn't actually use -i 67108864) Partition sizes range from ~200 GB to 1.5 TB. A small number of directories, perhaps a dozen. About 1/2 the files are small, a few KB, the other half are large, 500MB-25GB. Goals are to minimize seeking and use space efficiently. Files are written sequentially, read mostly (99.99%) sequentially, no editing. I still think it may have something to do with a common resource such as disk cache, as it can affect other disks, including swap. Hmmm, does swap use the disk cache? But now it appears that FFS tuning is the cause of the bottleneck. Do these tuning parameters increase the number of some data structure needed? Can I crank that up? Do I have to change the FFS tuning? Suggestions? _______________________________________________ freebsd-performance@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@..." |
|
|
Re: ZFS Re: A specific example of a disk i/o problem
by Thomas Backman
::
Rate this Message:
On Oct 5, 2009, at 6:05 PM, Dieter wrote:
> In message <E316139E-FFCF-432F-8DCE-62B120C38E55@...>, > Thomas Backman writes: > >> I run 8.0-RC1/amd64 with ZFS on an A64 3200+ with 2GB RAM and an old >> 80GB 7200rpm disk. >> >> My problem is that I get completely unacceptable latency on console >> IO >> (both via SSH and serial console) when the system is performing disk >> IO. The worst case I've noticed yet was when I tried copying a core >> dump from a lzjb compressed ZFS file system to a gzip-9 compressed >> one, to compare the file size/compression ratio. screen(1) took at >> LEAST ten seconds - probably a bit more - I'm not exaggerating here - >> to switch to another window, and an "ls" in an empty directory also >> about 5-10 seconds. > > You might find the "RELENG_7 heavy disk = system crawls" thread > interesting: > > } I didn't actually solve it or do anything. > } I just upgraded to RELENG_8. > } > } Now it's behaving more like FreeBSD should. > } I can do sequential reads/writes and still > } use kbd/mouse/X11/buildworld and so on. Doesn't really help much I'm afraid, since 8.0-RC1 = RELENG_8 = stable/ 8. Been running current/stable-8 since May. Regards, Thomas _______________________________________________ freebsd-performance@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@..." |
|
|
Re: tuning FFS for large files Re: A specific example of a disk i/o problem
by Bruce Evans-4
::
Rate this Message:
On Mon, 5 Oct 2009, Dieter wrote:
> I found a clue! The problem occurs with my big data partitions, > which are newfs-ed with options intended to improve things. > > Reading a large file from the normal ad4s5b partition only delays other > commands slightly, as expected. Reading a large file from the tuned > ad4s11 partition yields the delay of minutes for other i/o. > ... > Here is the newfs command used for creating large data partitions: > newfs -e 57984 -b 65536 -f 8192 -g 67108864 -h 16 -i 67108864 -U -o time $partition Any block size above the default (16K) tends to thrash and fragment buffer cache virtual memory. This is obviously a good pessimization with lots of small files, and apparently, as you have found, it is a good pessimization with a few large files too. I think severe fragmentation can easily take several seconds to recover from. The worst case for causing fragmentaion is probably a mixture of small and large files. Some users fear fs consistency bugs with block sizes >= 16K, but I've never seen them cause any bugs ecept performance ones. > Even this isn't tuned the way I wanted to. > -g * -h must be less than 4 G due to 32 bit problem (system panics). The panic is now avoided in some versions of FreeBSD (-8 and -current at least). > Note the 32 bit problem is in the filesystem code, I'm running amd64. > IIRC there is a PR about this. (I'm assuming the bug hasn't been fixed yet) > Result is that I must specify -g and -h smaller than they should be. I bet you can't see any difference (except the panic) from enlarging -g and -h. > And they have way more inodes than needed. (IIRC it doesn't actually > use -i 67108864) It has to have at least 1 inode per cg, and may as well have a full block of them, which gives a fairly large number of inodes especially if the block size is too large (64K), so the -i ratio is limited. Bruce _______________________________________________ freebsd-performance@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@..." |
|
|
Re: ZFS Re: A specific example of a disk i/o problem
by O. Hartmann-4
::
Rate this Message:
Thomas Backman wrote:
> On Oct 5, 2009, at 6:05 PM, Dieter wrote: > >> In message <E316139E-FFCF-432F-8DCE-62B120C38E55@...>, Thomas >> Backman writes: >> >>> I run 8.0-RC1/amd64 with ZFS on an A64 3200+ with 2GB RAM and an old >>> 80GB 7200rpm disk. >>> >>> My problem is that I get completely unacceptable latency on console IO >>> (both via SSH and serial console) when the system is performing disk >>> IO. The worst case I've noticed yet was when I tried copying a core >>> dump from a lzjb compressed ZFS file system to a gzip-9 compressed >>> one, to compare the file size/compression ratio. screen(1) took at >>> LEAST ten seconds - probably a bit more - I'm not exaggerating here - >>> to switch to another window, and an "ls" in an empty directory also >>> about 5-10 seconds. >> >> You might find the "RELENG_7 heavy disk = system crawls" thread >> interesting: >> >> } I didn't actually solve it or do anything. >> } I just upgraded to RELENG_8. >> } >> } Now it's behaving more like FreeBSD should. >> } I can do sequential reads/writes and still >> } use kbd/mouse/X11/buildworld and so on. > > Doesn't really help much I'm afraid, since 8.0-RC1 = RELENG_8 = > stable/8. Been running current/stable-8 since May. > > Regards, > Thomas > _______________________________________________ > freebsd-performance@... mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to > "freebsd-performance-unsubscribe@..." Is this really ZFS-bound? I also saw (and still see!) massive performance impacts when a lot of disk activities, especially when compiling large packages (done on UFS2 disks). Copying data from one ZFS drive to (on different harddrive) another ZFS drive (which is compressed) doesn't impact performance that much. When the box hit this performance issue, console, X11 and other activities tend to be stuck for minutes! This happens on an UP box (Athlon64 3500+, 2 GB ECC RAM, 2x 250 GB WD SATA-II disks and 1 TB WD SATA-II disk (1x 250 GB UFS2 for system, 1x 250 GB ZFS compressed for backup, 1x 1 TB ZFS holding /home). But this impact is also noticable on my lab's machine: Quad core Intel Q6600 CPU at 3,0 GHZ, 8 GB RAM, 1x 320 GB SATA-II UFS2 disk for system, 2x SATA-II 500 ZFS and 1x 750 GB disks ZFS and even on a 8 core, two socket Dell PowerEdge 1950-III box with two XEON CPUs running at 2,5 GHz, 16 GB RAM and two SATA-II harddrives attached to the built in SAS controller. Maybe this is of interest: http://www.phoronix.com/scan.php?page=article&item=freebsd8_ubuntu910&num=1 Watch the threaded I/O impact ... Regards, Oliver _______________________________________________ freebsd-performance@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@..." |
|
|
Re: ZFS Re: A specific example of a disk i/o problem
by Thomas Backman
::
Rate this Message:
On Oct 6, 2009, at 10:57 AM, O. Hartmann wrote:
> Thomas Backman wrote: >> On Oct 5, 2009, at 6:05 PM, Dieter wrote: >>> In message <E316139E-FFCF-432F-8DCE-62B120C38E55@...>, >>> Thomas Backman writes: >>> >>>> I run 8.0-RC1/amd64 with ZFS on an A64 3200+ with 2GB RAM and an >>>> old >>>> 80GB 7200rpm disk. >>>> >>>> My problem is that I get completely unacceptable latency on >>>> console IO >>>> (both via SSH and serial console) when the system is performing >>>> disk >>>> IO. The worst case I've noticed yet was when I tried copying a core >>>> dump from a lzjb compressed ZFS file system to a gzip-9 compressed >>>> one, to compare the file size/compression ratio. screen(1) took at >>>> LEAST ten seconds - probably a bit more - I'm not exaggerating >>>> here - >>>> to switch to another window, and an "ls" in an empty directory also >>>> about 5-10 seconds. >>> >>> You might find the "RELENG_7 heavy disk = system crawls" thread >>> interesting: >>> >>> } I didn't actually solve it or do anything. >>> } I just upgraded to RELENG_8. >>> } >>> } Now it's behaving more like FreeBSD should. >>> } I can do sequential reads/writes and still >>> } use kbd/mouse/X11/buildworld and so on. >> Doesn't really help much I'm afraid, since 8.0-RC1 = RELENG_8 = >> stable/8. Been running current/stable-8 since May. >> Regards, >> Thomas >> _______________________________________________ >> freebsd-performance@... mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-performance >> To unsubscribe, send any mail to "freebsd-performance-unsubscribe@... >> " > > Is this really ZFS-bound? I also saw (and still see!) massive > performance impacts when a lot of disk activities, especially when > compiling large packages (done on UFS2 disks). Copying data from one > ZFS drive to (on different harddrive) another ZFS drive (which is > compressed) doesn't impact performance that much. > > When the box hit this performance issue, console, X11 and other > activities tend to be stuck for minutes! This happens on an UP box > (Athlon64 3500+, 2 GB ECC RAM, 2x 250 GB WD SATA-II disks and 1 TB > WD SATA-II disk (1x 250 GB UFS2 for system, 1x 250 GB ZFS compressed > for backup, 1x 1 TB ZFS holding /home). > > But this impact is also noticable on my lab's machine: Quad core > Intel Q6600 CPU at 3,0 GHZ, 8 GB RAM, 1x 320 GB SATA-II UFS2 disk > for system, 2x SATA-II 500 ZFS and 1x 750 GB disks ZFS and even on a > 8 core, two socket Dell PowerEdge 1950-III box with two XEON CPUs > running at 2,5 GHz, 16 GB RAM and two SATA-II harddrives attached to > the built in SAS controller. > > Maybe this is of interest: > http://www.phoronix.com/scan.php?page=article&item=freebsd8_ubuntu910&num=1 > > Watch the threaded I/O impact ... > > Regards, > Oliver who added it to the subject line :) I just tried it to my one UFS filesystem, and while screen(1) DID remain 100% responsive, everything didn't. vim worked OK most of the time, but other FS ops on the same disk... oh no. I aborted the "file / etc/*" after 57 seconds. Tried it again after stopping the disk IO (cat /dev/zero > /bootdir/filename) - 1.52 seconds. This raises the question: is this some kind of hardware specific issue? If so, what hardware? I can't think of anything my computer would have in common with the ones you've listed! I mean, come on, FreeBSD's IO performance can't be this abysmal for everybody or nobody would use it for serious applications. Something must be wrong for a few of us, but where and why? Regards, Thomas _______________________________________________ freebsd-performance@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@..." |
|
|
Re: tuning FFS for large files Re: A specific example of a disk i/o problem
by dieter-7
::
Rate this Message:
> > I found a clue! The problem occurs with my big data partitions,
> > which are newfs-ed with options intended to improve things. > > > > Reading a large file from the normal ad4s5b partition only delays other > > commands slightly, as expected. Reading a large file from the tuned > > ad4s11 partition yields the delay of minutes for other i/o. > > ... > > Here is the newfs command used for creating large data partitions: > > newfs -e 57984 -b 65536 -f 8192 -g 67108864 -h 16 -i 67108864 -U -o time $partition > > Any block size above the default (16K) tends to thrash and fragment buffer > cache virtual memory. This is obviously a good pessimization with lots of > small files, and apparently, as you have found, it is a good pessimization > with a few large files too. I think severe fragmentation can easily take > several seconds to recover from. The worst case for causing fragmentaion > is probably a mixture of small and large files. Is there any way to avoid the "thrash and fragment buffercache virtual memory" problem other than keeping the block size 16K or smaller? > Some users fear fs consistency bugs with block sizes >= 16K, but I've never > seen them cause any bugs ecept performance ones. Yep, many TB of files on filesystems created with above newfs command and no corruption/consistency problems. > > And they have way more inodes than needed. (IIRC it doesn't actually > > use -i 67108864) > > It has to have at least 1 inode per cg, and may as well have a full block > of them, which gives a fairly large number of inodes especially if the > block size is too large (64K), so the -i ratio is limited. I converted a few filesystems to the default. In addition to losing space, fsck time went through the roof. So back to playing with newfs options. For some reason, larger block/frag sizes allow fewer cylinder groups, which reduces the number of inodes more than the larger block size increases it. From my reading of the newfs man page, -c only allows making cylinder groups smaller, not larger, and that appears to be the case in practice. default: newfs -U /dev/ad14s4 /dev/ad14s4: 431252.6MB (883205320 sectors) block size 16384, fragment size 2048 using 2348 cylinder groups of 183.72MB, 11758 blks, 23552 inodes. Filesystem 1M-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/ad14s4 417678 0 384263 0% 2 55300092 0% fsck -fp: real 0m37.165s Attempt to reduce number of inodes: newfs -U -i 134217728 -g 134217728 -h 16 -e 261129 /dev/ad14s4 density reduced from 134217728 to 3676160 /dev/ad14s4: 431252.6MB (883205320 sectors) block size 16384, fragment size 2048 using 1923 cylinder groups of 224.38MB, 14360 blks, 64 inodes. Filesystem 1M-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/ad14s4 431162 0 396669 0% 2 123068 0% fsck -fp: real 0m32.687s Bigger block size: newfs -U -i 134217728 -g 134217728 -h 16 -e 261129 -b 65536 /dev/ad14s4 increasing fragment size from 2048 to block size / 8 (8192) density reduced from 134217728 to 14860288 /dev/ad14s4: 431252.6MB (883205312 sectors) block size 65536, fragment size 8192 using 119 cylinder groups of 3628.00MB, 58048 blks, 256 inodes. Filesystem 1M-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/ad14s4 431230 0 396731 0% 2 30460 0% fsck -fp: real 0m3.144s Bigger block size and bigger frag size: newfs -U -i 134217728 -g 134217728 -h 16 -e 261129 -b 65536 -f 65536 /dev/ad14s4 density reduced from 134217728 to 66846720 /dev/ad14s4: 431252.6MB (883205248 sectors) block size 65536, fragment size 65536 using 27 cylinder groups of 16320.56MB, 261129 blks, 512 inodes. Filesystem 1M-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/ad14s4 431245 0 396745 0% 2 13820 0% fsck -fp: real 0m0.369s With -b 65536 -f 65536 I'm finally approaching a reasonable number of inodes (even less would be better). The fsck time varies by a factor of over 100, and results are roughly similar on filesystems with files in them. _______________________________________________ freebsd-performance@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@..." |
| Free embeddable forum powered by Nabble | Forum Help |
