improvements of at least 4 times in untarring and roughly 100 to 500 times
on file creation in big directories. Lookup of files was O(n*n) and is now
O(1) even for file creation. Free spaces in the directory are kept in a
seperate list for fast file creation.
The postmark benchmark gives:
UDF old:
pm>set transactions 2000
pm>set number 3000
pm>run
Creating files...Done
Performing transactions..........Done
Deleting files...Done
Time:
1593 seconds total
681 seconds of transactions (2 per second)
Files:
3956 created (2 per second)
Creation alone: 3000 files (4 per second)
Mixed with transactions: 956 files (1 per second)
990 read (1 per second)
1010 appended (1 per second)
3956 deleted (2 per second)
Deletion alone: 2912 files (9 per second)
Mixed with transactions: 1044 files (1 per second)
Data:
5.26 megabytes read (3.38 kilobytes per second)
21.93 megabytes written (14.10 kilobytes per second)
pm>
UDF new:
pm>set transactions 2000
pm>set number 3000
pm>run
Creating files...Done
Performing transactions..........Done
Deleting files...Done
Time:
19 seconds total
3 seconds of transactions (666 per second)
Files:
3956 created (208 per second)
Creation alone: 3000 files (230 per second)
Mixed with transactions: 956 files (318 per second)
990 read (330 per second)
1010 appended (336 per second)
3956 deleted (208 per second)
Deletion alone: 2912 files (970 per second)
Mixed with transactions: 1044 files (348 per second)
Data:
5.26 megabytes read (283.66 kilobytes per second)
21.93 megabytes written (1.15 megabytes per second)
> make makeiplcookie() return PSL bits via ipl2psl_table[]
> rather than IPL_FOO indexes
because ipl2psl_table[] could be updated during autoconf(9)
and we can't use it as cookie before cpu_configure(9).
unlock the source directory again on exit. The stub that doesn't allow
cross directory renames for now jumped to the wrong exit point and thus
left a locked directory node that paniced on next locking.
into two parts so that some of the routines could be used by rump.
Now that rump uses both vfs_subr and vfs_subr2 and there is no
reason to keep two files lying around, re-unite them.
sensitive information in memory longer than necessary
(We could make this depend on ~ECHO or so, but this would be an API
change and I don't think it is worth the effort.)
Why is there a "Makefile.boot" used here, and a "Makefile.booters"
used one level up, with redundant stuff between both of them? This all
used to be so clean...
For now, we include kernel revision as a way of allowing users to
notice that boot blocks have gotten very old, so the first line of the
printout looks like this (depending on the particular block):
>> NetBSD/x86 BIOS Boot, Revision 3.4 (from NetBSD 5.0)
This may be changed a bit pending feedback. (Some people think that
the kernel revision shouldn't be there at all, for example.)
Part of the project to assure that bit-identical sources produce
bit-identical release binaries.
const char bootprog_kernrev[] = "4.99.70";
For now, we still also include the builder name and date and such, so
that we don't break anything, but those are (probably) on the way out.
Part of the "bit-identical sources yield bit-identical release files"
project.
