On Tue, 7 Jan 2003 [EMAIL PROTECTED] wrote: > In message <01e701c2b62b$db07ddd0$471b3dd4@dual>, "Willem Jan Withagen" writes: > >I was able to copy the full 100+Gb. > >Next I'm going to try and fill the disk to the max as user, but i guess it'll not >trigger this bug. > > > >And to that fact I have a question: > > At the moment 8% of the disk is reserved. > > It being a 170Gb raid, that wastes a good 13,6Gb, which I find at lot. > > tunefs lets me bring that down to 5% = 8,5Gb without speed penalty. > > But is for this size of spare space such a large threshold really required?? > > And IF i would like to experiment, where do I look for the knop to turn?? > > Basically you don't need to reserve anything, but as you get closer to > filling the disk the time to find a free space increases rapidly and > your files get very fragmented. Trouble is: they never get defragmented > unless you copy them (or do a full dump/restore).
File get quite fragmented (enough to lose a factor of 2 or so of the disk's bandwidth) even when the disk is almost empty. Then they don't get defragmented unless you copy them, etc. The Real Fragmentation that occurs when a disk is nearly full loses a much larger factor of the disk's bandwidth. > I'm not sure how to nail the "right" number of % down, and I'm sure > that both Kirk and I would like to hear your numbers :-) I postprocess output from Kirk's block number printing program to produce fragmentation estimates. All (non-null) seeks are considered to be fragmentation. A (logical) non-null seek seems to be normal for about 10% of (logical) i/o's even in the favourable case of files created by copying to an initially empty filesystem (this is for small files like the ones in FreeBSD's src tree). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
