Dag-Erling Smorgrav wrote:
No, I don't think there's much point in doing that before Kirk
McKusick removes the restrictions on the soft updates code. When that
happens, we can make soft updates non-optional and turn on soft
updates on all file systems by default.
I hope *that* doesn't
jo...@gnu.org (Joel Ray Holveck) writes:
As we all know, tunefs -o space will hurt write performance. Will it
hurt read performance? If I don't care about install-time speed, but
do care about run-time speed and free space, should I populate my
filesystems at install time with space
On Sat, May 29, 1999 at 12:03:54AM -0500, Joel Ray Holveck wrote:
How do people like to set up their filesystems these days? I've heard
of people who like one big fs (not generally usable anymore because of
the 1024 cyl limit), others who like the small root fs and one big fs
for everything
Joel Ray Holveck jo...@gnu.org writes:
About five minutes ago, I realized that one problem is that I recently
installed a new disk, and forgot to enable softupdates on it (doh!).
From the little I know, I don't quite understand why softupdates is a
tunefs parameter, instead of a mount flag.
On 29 May 1999 at 0:03, Joel Ray Holveck jo...@gnu.org wrote:
[snip]
How do people like to set up their filesystems these days? I've heard
of people who like one big fs (not generally usable anymore because of
the 1024 cyl limit), others who like the small root fs and one big fs
for
Peter Jeremy wrote:
Michael R. Wayne wa...@msen.com wrote:
Long ago, back when disks were small, slow and expensive, someone
wrote a program that properly defragged a Unix filesystem.
If it was that long ago, chances are it is pre-FFS - the System 5
File System and its predecessors. I
You might try unmounting the filesystem and doing
tunefs -o space /dev/rawdevice
(which can also be done at newfs time). You may find that the
performance, especially write performance, isn't too good.
I've been looking over FS performance tuning, trying to get my
compiles to go a bit
On 29 May 1999, Joel Ray Holveck wrote:
You might try unmounting the filesystem and doing
tunefs -o space /dev/rawdevice
(which can also be done at newfs time). You may find that the
performance, especially write performance, isn't too good.
I've been looking over FS performance
David Scheidt wrote:
On Wed, 26 May 1999, Graeme Tait wrote:
It contains about 900,000 files, most of which are small, occupying
around 2-5 fragments. The small files are updated monthly from a tar
snip
However, I don't understand how the FFS works, so I'm just probing and
guessing
On 27 May 1999, Graeme Tait proclaimed:
BTW, I realize there is probably a better way to do this (database,
etc.), and we are thinking in that direction, but for the moment we
have a legacy setup and not much time to rework it. Also, I would have
thought that having many tiny files was not
-Original Message-
From: Dom Mitchell [SMTP:dom.mitch...@palmerharvey.co.uk]
Sent: Thursday, May 27, 1999 11:20 AM
To: Graeme Tait
Cc: David Scheidt; freebsd-hackers@freebsd.org; i...@boatbooks.com
Subject: Re: File system gets too fragmented ???
It sounds like you've
On Thu, 27 May 1999, Graeme Tait wrote:
I've received several answers along this direction, but I want to emphasize
one
point that I think is being overlooked. When the filesystem is fresh and a
new
archive is expanded to create ~900,000 small files each of 2-5 512 byte frags
in
On May 27, 5:07am, Graeme Tait wrote:
} Subject: Re: File system gets too fragmented ???
} I've received several answers along this direction, but I want to emphasize
one
} point that I think is being overlooked. When the filesystem is fresh and a
new
} archive is expanded to create ~900,000
On May 26, 6:59pm, Graeme Tait wrote:
} Subject: File system gets too fragmented ???
} The filesystem is built with 4096 byte blocks, 512 byte fragments, and
} 2048 bytes/inode, and is mounted 'async noatime'.
}
} It contains about 900,000 files, most of which are small, occupying
} around 2-5
On Thu, May 27, 1999 at 07:15:56AM -0700, Don Lewis wrote:
}
} The problem seems to be that with successive updates that slightly change
the
} size of files, or add or delete files, that a large number of unallocated
} fragments are created.
Long ago, back when disks were small, slow and
It might help somewhat if a file that grows by a fragment can allocate
the free fragment immediately preceeding it instead of being relocated
to a fresh block. I don't know if FFS does this or not.
Really? FFS allocates free fragments with bitmap, so it should be able to
find free
On Thu, 27 May 1999, Don Lewis wrote:
On May 26, 6:59pm, Graeme Tait wrote:
} The filesystem is built with 4096 byte blocks, 512 byte fragments, and
} 2048 bytes/inode, and is mounted 'async noatime'.
If a file shrinks by one fragment, it'll most likely leave a one
fragment gap in the
Michael R. Wayne wa...@msen.com wrote:
Long ago, back when disks were small, slow and expensive, someone
wrote a program that properly defragged a Unix filesystem.
If it was that long ago, chances are it is pre-FFS - the System 5
File System and its predecessors. I remember using a Motorola
I previously posted to 'questions' about a filesystem that was reported
full when df -ik showed plenty of space remaining, but got no useful
answers, so I'm hoping this list can offer some assistance.
[Please respond to me directly, as I'm not subscribed here.]
The filesystem is built with
On Wed, 26 May 1999, Graeme Tait wrote:
It contains about 900,000 files, most of which are small, occupying
around 2-5 fragments. The small files are updated monthly from a tar
snip
However, I don't understand how the FFS works, so I'm just probing and
guessing as to what's going on here.
I missed the original post, so may be mislead
(The extract below doesn't give all the symptoms)
David Scheidt wrote:
On Wed, 26 May 1999, Graeme Tait wrote:
It contains about 900,000 files, most of which are small, occupying
around 2-5 fragments. The small files are updated monthly
21 matches
Mail list logo
