On Sun, Aug 18, 2013 at 06:04:55PM +0200, Johnny Billquist wrote:
Looking at 2.11BSD, it looks like this:
struct direct {
[snip]
In NetBSD (fairly current):
struct dirent {
careful, you want struct direct, not struct dirent:
struct direct {
u_int32_t d_fileno;
On Sun, Aug 18, 2013 at 12:24:12PM -0400, Mouse wrote:
A directory may contain entries other than subdirectories. Since there
is no enforced ordering of entries in a directory, the whole directory
must be read to find all the subdirectories (unless 32767 subdirs are
found first, I
On 2013-08-19 08:41, David Holland wrote:
On Sun, Aug 18, 2013 at 06:04:55PM +0200, Johnny Billquist wrote:
Looking at 2.11BSD, it looks like this:
struct direct {
[snip]
In NetBSD (fairly current):
struct dirent {
careful, you want struct direct, not struct dirent:
On Sun, Aug 18, 2013 at 03:08:21PM +0200, Manuel Wiesinger wrote:
Hello,
I am working on a defrag tool for UFS2/FFSv2 as Google Summer of Code
Project.
The size of a directory offset is of type int32_t (see
src/sys/ufs/ufs/dir.h), which is a signed integer. So the maximum size
can be
On Mon, Aug 19, 2013 at 09:01:35AM +0200, Johnny Billquist wrote:
careful, you want struct direct, not struct dirent:
Hmm. Probably a good point. I was wondering if NetBSD had just
renamed direct to dirent, but that was just me getting confused
then. (And lazy, since I didn't really
On Mon, Aug 19, 2013 at 1:01 PM, David Holland dholland-t...@netbsd.org wrote:
Speed. There's a moderately famous paper A trace-driven analysis of
the UNIX 4.2 BSD file system -- you might have heard of it :-)
Actually I haven't. I should look it up. Thanks.
Yeah, that one's worth a
On 08/19/13 09:31, David Laight wrote:
For defrag I'd have though you'd work from the inode table and treat
directories no different from files.
That's what I'm doing.
I have an additional optimisation step, which tries to move files in the
same directory, so that they are stored
On 2013-08-19 15:56, Manuel Wiesinger wrote:
On 08/19/13 09:31, David Laight wrote:
For defrag I'd have though you'd work from the inode table and treat
directories no different from files.
That's what I'm doing.
I have an additional optimisation step, which tries to move files in the
same
On 08/19/13 17:52, Johnny Billquist wrote:
I confess I have not studied the topic in enough detail. Are there any
research on what strategies are better when it comes to locating files
in a file system in proximity of each other? Is a common directory the
best indicator on where to place files,
