Re: 4bsd fuzzy runq
Elijah Buck wrote:
Hi,
I'm looking at the code for 4bsd fuzzy run queues in kern_switch.c
The relevant bit:
if (fuzz 1) {
int count = fuzz;
int cpu = PCPU_GET(cpuid);
struct thread *td2;
td2 = td = TAILQ_FIRST(rqh);
while (count-- td2) {
if (td-td_lastcpu == cpu) {
this should be td2. The bug is mine..
and I wondered why the code commited never had the same result as that
I tested in another tree.
td = td2;
break;
}
td2 = TAILQ_NEXT(td2, td_runq);
}
...return(td)
The purpose of this code appears to be to look through the runq to a depth
defined by fuzz for a thread that was last run on the current cpu.
Here are the cases I see:
1.) if (td_lastcpu == cpu) on the first iteration then TAILQ_FIRST(rqh) is
the selected thread (because of the break).
2.) if (td_lastcpu != cpu) on the first iteration then td is never set
again, and so (td_lastcpu != cpu) is always true. So, again,
TAILQ_FIRST(rqh) will be selected (because count will reach 0).
Which doesn't seem right (since that's what the else clause does). What am I
missing here?
Thanks,
Elijah
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
BDB corrupt
Please, can anybody explain what is the problem with BDB (1.86). Is there known caveats of using BDB? Is there some rules which guarantee from curruption or it is fully undesirable to use BDB under high load? It is important for me because of using BDB in my project. On Fri, May 09, 2008 at 01:52:46PM +0200, Joerg Sonnenberger wrote: As one of the persons hacking on pkg_install in pkgsrc/NetBSD, I would *strongly* advisy you against storing the files only in a bdb file. The change of major and complete corruption with bdb185 is high, consider pulling the plug in the middle of a long update. Sunday, May 11, 2008, 5:38:25 PM, you wrote: GC +1. BDB is quite easy to corrupt... -- Best regards, Anthonymailto:[EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BDB corrupt
On Monday 12 May 2008 10:38, Anthony Pankov wrote: Please, can anybody explain what is the problem with BDB (1.86). Is there known caveats of using BDB? Is there some rules which guarantee from curruption or it is fully undesirable to use BDB under high load? It is important for me because of using BDB in my project. Interesting. I would have thought that the two processes find out advantages and problems of proposed solutions and choose a solution had a natural ordering other than the one you seem to be using. Jonathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
openbsd solution to mounted umass removal
I've just came back from a good 2 week vacation and catching up on news. In release notes for OpenBSD 4.3 I see the following: http://openbsd.org/43.html Filesystems on USB devices are automatically dismounted if the device is disconnected. Does anybody have more [technical] details on this? Thanks. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
i386 cpu_reset_real: code/comment mismatch
This is not a real issue, just a code clarification. First a snippet from sys/i386/i386/vm_machdep.c, cpu_reset_real() /* * Attempt to force a reset via the Reset Control register at * I/O port 0xcf9. Bit 2 forces a system reset when it is * written as 1. Bit 1 selects the type of reset to attempt: * 0 selects a soft reset, and 1 selects a hard reset. We * try to do a soft reset first, and then a hard reset. */ outb(0xcf9, 0x2); outb(0xcf9, 0x6); I think that the comment is correct up to but not including the last sentence. Writing 0x2 sets bit 1 to 1 (thus selecting hard reset), and writing 0x6 sets both bits 2 and 1 to 1 (thus performing hard reset). So we always just do a hard reset, no trying of soft reset (would it even make sense to do the last line of the comment says). -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding .db support to pkg_tools
On Sun, 11 May 2008 21:07:41 +0200, Jos Backus [EMAIL PROTECTED] wrote: On Sun, May 11, 2008 at 06:38:25AM -0700, Garrett Cooper wrote: +1. BDB is quite easy to corrupt... If we're going to use a binary file format, please consider using SQLite instead. It has the right license, a nice API (transactions!) and is robust enough for yum to use it for a similar purpose. One of the reasons for using BDB is that it is in the base system, SQLite however is not. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding .db support to pkg_tools
On Mon, May 12, 2008 at 05:12:56PM +0200, Anders Nore wrote: On Sun, 11 May 2008 21:07:41 +0200, Jos Backus [EMAIL PROTECTED] wrote: On Sun, May 11, 2008 at 06:38:25AM -0700, Garrett Cooper wrote: +1. BDB is quite easy to corrupt... If we're going to use a binary file format, please consider using SQLite instead. It has the right license, a nice API (transactions!) and is robust enough for yum to use it for a similar purpose. One of the reasons for using BDB is that it is in the base system, SQLite however is not. Interesting discussion, and there's some irony in it (SQLite uses a very BDB-like a storage medium, despite being a relational database system). SQLite's license is compatible/friendly, its API is decent, the source is fairly small and binary footprint (disk and memory both) are small, and it includes tools for dumping databases to ASCII so developers aren't forced to write DB dumping tools and users don't have to resort to using hexdump. A few things worth pointing out: With regards to DB1.x being easily corrupted, this is true, and I have heard claims of it from a couple developer-folk I worked with many years ago at Best Internet. On the other hand, SQLite appears to have a history of this as well, although those bugs have been fixed each and every time: http://www.sqlite.org/cvstrac/wiki?p=DatabaseCorruption Secondly, the following FAQ entry and documentation from Mozilla is of concern, specifically the last paragraph of the FAQ entry, since there is ongoing work in the ports collection to support parallel building, which would surely use fork() or locks): http://www.sqlite.org/faq.html#q6 http://developer.mozilla.org/en/docs/Storage#SQLite_Locking Thirdly, there is the concern of disk space. There are a substantial number of users who have FreeBSD on embedded systems or systems with little or no space, who use binary packages (pkg_add -r), which of course still makes use of /var/db/pkg. SQLite DBs grow over time, and don't shrink in size unless you use auto-vacuum mode or execute the VACUUM query: http://www.sqlite.org/faq.html#q12 Fourthly, it doesn't sound as if storage SQLite databases on an NFS mount is a good idea, and I've a feeling some people have /var NFS mounted (diskless systems for example): http://www.sqlite.org/faq.html#q5 Finally, there's the concern about the SQLite file format changing. Sometimes they're backwards-compatible, other times not. http://www.sqlite.org/formatchng.html http://www.sqlite.org/fileformat.html Just stuff to consider. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding .db support to pkg_tools
On Mon, May 12, 2008 at 08:47:53AM -0700, Jeremy Chadwick wrote: Secondly, the following FAQ entry and documentation from Mozilla is of concern, specifically the last paragraph of the FAQ entry, since there is ongoing work in the ports collection to support parallel building, which would surely use fork() or locks): I don't think this is applicable. Thirdly, there is the concern of disk space. There are a substantial number of users who have FreeBSD on embedded systems or systems with little or no space, who use binary packages (pkg_add -r), which of course still makes use of /var/db/pkg. SQLite DBs grow over time, and don't shrink in size unless you use auto-vacuum mode or execute the VACUUM query: It is trivial to recreate the database, so I don't think this is a concern either. I should point again that it will result in a non-trivial increase in size. Fourthly, it doesn't sound as if storage SQLite databases on an NFS mount is a good idea, and I've a feeling some people have /var NFS mounted (diskless systems for example): Same applies to BDB and basically anything that depends on fcntl to work. Basically, as long as you have /var per host (you don't share /var, do you?), it will just work as the *local* locks are working. The problem with NFS comes form the fact that multiple hosts might not share them. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: openbsd solution to mounted umass removal
Andriy Gapon wrote: Filesystems on USB devices are automatically dismounted if the device is disconnected. Does anybody have more [technical] details on this? Modified files: sys/dev/usb: umass.c sys/scsi : sdvar.h sd.c sys/kern : vfs_default.c vfs_subr.c Log message: Allow to pull out an usb stick with ffs filesystem while mounted and a file is written onto the stick. Without these fixes the machine panics or hangs. The usb fix calls the callback when the stick is pulled out to free the associated buffers. Otherwise we have busy buffers for ever and the automatic unmount will panic. The change in the scsi layer prevents passing down further dirty buffers to usb after the stick has been deactivated. In vfs the automatic unmount has moved from the function vgonel() to vop_generic_revoke(). Both are called when the sd device's vnode is removed. In vgonel() the VXLOCK is already held which can cause a deadlock. So call dounmount() earlier. -- Alex Dupre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding .db support to pkg_tools
On Mon, May 12, 2008 at 05:12:56PM +0200, Anders Nore wrote: One of the reasons for using BDB is that it is in the base system, SQLite however is not. I'm aware of that. But I believe that the pain and suffering of importing and maintaining SQLite in the base (that is, the cost) is outweighed by its richer feature set and higher-level API, facilitating easier tools development. -- Jos Backus jos at catnook.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386 cpu_reset_real: code/comment mismatch
On Mon, 12 May 2008 17:34:35 +0300 Andriy Gapon [EMAIL PROTECTED] wrote: This is not a real issue, just a code clarification. First a snippet from sys/i386/i386/vm_machdep.c, cpu_reset_real() /* * Attempt to force a reset via the Reset Control register at * I/O port 0xcf9. Bit 2 forces a system reset when it is * written as 1. Bit 1 selects the type of reset to attempt: * 0 selects a soft reset, and 1 selects a hard reset. We * try to do a soft reset first, and then a hard reset. */ outb(0xcf9, 0x2); outb(0xcf9, 0x6); I think that the comment is correct up to but not including the last sentence. Writing 0x2 sets bit 1 to 1 (thus selecting hard reset), and writing 0x6 sets both bits 2 and 1 to 1 (thus performing hard reset). So we always just do a hard reset, no trying of soft reset (would it even make sense to do the last line of the comment says). It looks to me as if the comment was added retrospectively by someone who got the two bits mixed-up when reading the source. If bits 1 and 2 were the other way around, it would be code for a soft-reset followed by a hard-reset. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: BDB corrupt
So, can anyone make clear about BDB 1.86 (which is a part of base system). When 1. there is no need for SQL 2. processes are sharing db file in concurrent mode (key=value pair) 3. reading/writing = 60%/40% the first idea is to use BDB. Because BDB: 1. do not need additional installation 2. is part of base system which mean it is mature, reliable and stable (otherwise why BDB is still a part of FreeBSD?) Discussion Adding .db support to pkg_tools reveal BDB ability to corrupt data. Can anyone suggest BDB alternative (not GPLed)? Monday, May 12, 2008, 1:53:00 PM, you wrote: JM On Monday 12 May 2008 10:38, Anthony Pankov wrote: Please, can anybody explain what is the problem with BDB (1.86). Is there known caveats of using BDB? Is there some rules which guarantee from curruption or it is fully undesirable to use BDB under high load? It is important for me because of using BDB in my project. JM Interesting. I would have thought that the two processes find out advantages JM and problems of proposed solutions and choose a solution had a natural JM ordering other than the one you seem to be using. JM Jonathan -- Best regards, Anthonymailto:[EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BDB corrupt
On Mon, 12 May 2008 22:35:31 +0400 Anthony Pankov [EMAIL PROTECTED] wrote: Because BDB: 1. do not need additional installation 2. is part of base system which mean it is mature, reliable and stable BDB in the base system is mature, reliable and stable *for what it's used for in the base system.* So long as your requirements are covered by that usage, you'll be ok. The uses I know of for BDB in the base system all consist of databases of relatively small items that are changed infrequently, and usually with a locking mechanism. From what you've said, this doesn't describe your requirements. More importantly, from what other people are saying, your requirements are ones for which it's known that BDB is *not* reliable, or otherwise unsuitable. In particular, an effort is underway to allow parallel ports builds, which implies concurrent access to the database, which is a known source of problems for BDB. mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
[Patch] Using sysctl(8) to acquire info from different systems
I recently started using output from sysctl(8) to get information from
some FreeBSD systems in what I hope is a low-impact way.
I wanted to avoid installing or configuring any additional software on
the machines; as they didn't have an SNMP daemon running (and I'm not
the one who actually controls or runs them anyway), I was reluctant to
recommend making such changes to production systems.
But I did have a requirement to gather information as to resource
consumption on the production machines, so I thought that sysctl(8)
output might be of some use -- and it has (or so I believe).
But I ran into one mild annoyance: Once I got a script working to
collect data from one machine, and I then tried running the script
(configured to collect information on the same OIDs), things were OK ...
as long as the new system was running the same revision of FreeBSD.
I realize that there will be changes in supported OIDs over time. But
the current behavior of sysctl(8) is to (squawk unless -q is specified)
and bail as soon as it sees a request to report on the value of an OID
it doesn't know.
In my case, I believe it would be useful to provide an ability to tell
sysctl(8) to report on everything asked for that it does know, and
ignore the OIDs it doesn't know.
Is this percpetion so radical that I'm way off base? If so, please
educate me as to why.
Otherwise, I'll plan on filing a PR with the attached patch, which adds
-i to sysctl(8)'s flags -- and which appears to work as described above:
localhost(8.0-C)[1] uname -a
FreeBSD localhost 8.0-CURRENT FreeBSD 8.0-CURRENT #769: Mon May 12 07:17:44 PDT
2008 [EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/CANARY i386
localhost(8.0-C)[2] sysctl hw.ncpu kern.sched.quantum net.inet.ip.fw.enable
hw.ncpu: 1
sysctl: unknown oid 'kern.sched.quantum'
localhost(8.0-C)[3] sysctl -i hw.ncpu kern.sched.quantum net.inet.ip.fw.enable
hw.ncpu: 1
net.inet.ip.fw.enable: 1
localhost(8.0-C)[4] ^-i^-q
sysctl -q hw.ncpu kern.sched.quantum net.inet.ip.fw.enable
hw.ncpu: 1
localhost(8.0-C)[5]
Peace,
david
--
David H. Wolfskill [EMAIL PROTECTED]
I submit that conspiracy would be an appropriate collective noun for cats.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
Index: sysctl.8
===
RCS file: /cvs/freebsd/src/sbin/sysctl/sysctl.8,v
retrieving revision 1.64
diff -u -r1.64 sysctl.8
--- sysctl.828 Nov 2007 14:48:30 - 1.64
+++ sysctl.812 May 2008 19:14:08 -
@@ -82,6 +82,12 @@
is specified, or a variable is being set.
.It Fl h
Format output for human, rather than machine, readability.
+.It Fl i
+Ignore unknown OIDs.
+The purpose is to make use of
+.Nm
+for collecting data from a variety of machines (not all of which
+are necessarily running exactly the same software) easier.
.It Fl N
Show only variable names, not their values.
This is particularly useful with shells that offer programmable
Index: sysctl.c
===
RCS file: /cvs/freebsd/src/sbin/sysctl/sysctl.c,v
retrieving revision 1.88
diff -u -r1.88 sysctl.c
--- sysctl.c15 Oct 2007 20:00:19 - 1.88
+++ sysctl.c12 May 2008 19:07:34 -
@@ -58,8 +58,8 @@
#include string.h
#include unistd.h
-static int aflag, bflag, dflag, eflag, hflag, Nflag, nflag, oflag;
-static int qflag, xflag;
+static int aflag, bflag, dflag, eflag, hflag, iflag, Nflag, nflag;
+static int oflag, qflag, xflag;
static int oidfmt(int *, int, char *, u_int *);
static voidparse(char *);
@@ -89,7 +89,7 @@
setbuf(stdout,0);
setbuf(stderr,0);
- while ((ch = getopt(argc, argv, AabdehNnoqwxX)) != -1) {
+ while ((ch = getopt(argc, argv, AabdehiNnoqwxX)) != -1) {
switch (ch) {
case 'A':
/* compatibility */
@@ -110,6 +110,9 @@
case 'h':
hflag = 1;
break;
+ case 'i':
+ iflag = 1;
+ break;
case 'N':
Nflag = 1;
break;
@@ -185,6 +188,8 @@
len = name2oid(bufp, mib);
if (len 0) {
+ if (iflag)
+ return;
if (qflag)
exit(1);
else
pgpLMDzSeAALE.pgp
Description: PGP signature
Re: Adding .db support to pkg_tools
Hi,
On Fri, May 09, 2008 at 01:52:46PM +0200, Anders Nore wrote:
I'm working on adding .db support to the pkg_tools
I hope that you know that you're stepping into a hotly debated part of
the project... Good luck. My advice to you is to ignore any calls for
a 'complete rewrite' and to focus on releasing small patches from your
project rather than one big patch at the end. Back each patch up with
performance numbers (I suggest pkg_add gnome2-x (from a local package
source), pkg_version and pkg_delete -r glib-2.x).
The way I'm thinking of storing information to the .db is to name the
keys as the directory names in /var/db/pkg. And save the +* files in
the directories to the value element in the db, separated with a
special character or similar.
I think this is a really bad idea. The problem with the tools is not
with the files. It is that the files need to be parsed on each run,
often recursively, and your solution would not help at all.
The database(s) should just be a cache of the information stored in the
files. This is what the existing databases used by portupgrade and
NetBSD's tools do. They store the files and which ports installed them,
so that it is easy to do conflict resolution, and some pkg_info
operations.
In addition, what you need is a cache which stores {pkg_name,pkg_origin}
pairs, where both are unique keys with a 1:1 relationship, and then a
{pkg_name,pkg_dep_name} directed graph, which stores the dependency
network between ports (aslo replacing +REQUIRED_BY). Both can be
reconstructed if needed from the +CONTENTS files. You could do both in
BDB, but you'll be better off loading both into memory completely (as
needed), using C to do the queries, and just maintaining the database
when things change (on pkg_add or pkg_delete).
SQLite would make this job easier in some ways, but hurt in others. You
could use queries, which would make what was going on much more obvious,
but then it would be slower. You also have to fight the anti-SQLite
lobby.
Ignore people who talk about disk space on embedded systems. They're
just trolling. ;-) If they don't have the disk space for /var/db/pkg,
then they don't have the space for the ports themselves. Besides,
removing the redundant copy of +MTREE_DIRS for each package would save
more space (and is as easy as checking the CVS revision of the new file
in each package and updating a single master copy (even
/etc/mtree/BSD.local.dist), if it is newer).
With regards to locking, which someone raised, the package tools are a
long way away from parallel modifications to /var/db/pkg. People are
talking about parallel ports builds, but those have small windows where
the package database is being updated, and those updates need to be
sync'ed via a lock.
Regards,
-Jeremy
--
FreeBSD - Because the best things in life are free...
http://www.freebsd.org/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BDB corrupt
On May 12, 2008, at 1:38 AM, Anthony Pankov wrote: Please, can anybody explain what is the problem with BDB (1.86). Is there known caveats of using BDB? Is there some rules which guarantee from curruption or it is fully undesirable to use BDB under high load? It is important for me because of using BDB in my project. On Fri, May 09, 2008 at 01:52:46PM +0200, Joerg Sonnenberger wrote: As one of the persons hacking on pkg_install in pkgsrc/NetBSD, I would *strongly* advisy you against storing the files only in a bdb file. The change of major and complete corruption with bdb185 is high, consider pulling the plug in the middle of a long update. Sunday, May 11, 2008, 5:38:25 PM, you wrote: GC +1. BDB is quite easy to corrupt... BDB isn't ATOMic, like SQL or other DB backends. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BDB corrupt
Garrett Cooper wrote: On May 12, 2008, at 1:38 AM, Anthony Pankov wrote: Please, can anybody explain what is the problem with BDB (1.86). Is there known caveats of using BDB? Is there some rules which guarantee from curruption or it is fully undesirable to use BDB under high load? It is important for me because of using BDB in my project. On Fri, May 09, 2008 at 01:52:46PM +0200, Joerg Sonnenberger wrote: As one of the persons hacking on pkg_install in pkgsrc/NetBSD, I would *strongly* advisy you against storing the files only in a bdb file. The change of major and complete corruption with bdb185 is high, consider pulling the plug in the middle of a long update. Sunday, May 11, 2008, 5:38:25 PM, you wrote: GC +1. BDB is quite easy to corrupt... BDB isn't ATOMic, like SQL or other DB backends. You mean ACID probably. And there are plenty of SQL databases that aren't ACID either. (e.g. Mysql 4.x, Mysql 5.x w/o the right kind of backing store) -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
ZFS and mmap() datapoint.
I don't know exactly where this fits in the discussion, but I was using ghost v 14 to backup my XP box over SMB to a 7.0-RELEASE system using ZFS. After doing one backup, the second backup wouldn't proceed, so I erased the backup files and started fresh. The next attempt, I turned on the verify option in ghost. It claimed that the backup it was creating was corrupt. So I upgraded the FreeBSD machine to 7-STABLE. Started the backup again, same problem. So I checked into samba's options ... and it has an option that claims to turn off the mmap() usage of the daemon. It certainly slows the daemon, so it's doing something. Anyways... the backup was still corrupt. Obviously... this is testing at a high layer. Does the option in smb.conf turn off the use of mmap(). Is that moot because C libraries might use mmap() anyways? Is ghost the culprit here? I dunno. The ZFS array does handle linear reads and writes of large media files without detectable error. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding .db support to pkg_tools
I think this is a really bad idea. The problem with the tools is not with the files. It is that the files need to be parsed on each run, often recursively, and your solution would not help at all. Parsing one file isn't expensive; parsing several hundred files to find one bit of information is expensive. The database(s) should just be a cache of the information stored in the files. Bingo! As long as the .db version can be easily recreated from scratch from the master data stored in the same files as always, it doesn't really matter if the BDB is occasionally corrupted, as long as it can be rebuilt fairly quickly. So, the key points are: * Use the .db file for lookups that can't be done quickly against the existing data. In particular, look for operations where the pkg tools have to scan a lot of files to verify a single fact. * Ensure the .db file can be deleted and rebuilt from scratch from the data in the regular files. Tim Kientzle ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
