Date: Sun, 07 Jan 1996 20:36:21 +0100 From: Poul-Henning Kamp <phk@critter.tfs.com> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: hackers@freebsd.org Subject: Re: Add new slice to running system, comments? Message-ID: <9043.821043381@critter.tfs.com> In-Reply-To: Your message of "Sun, 07 Jan 1996 21:03:18 %2B1030." <199601071033.VAA20309@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Have you tried mounting the msdos fs, and using the vn driver for > > swapping on the windows file ? > > This still means that swap operations have to go through the FAT filesystem > code, which is slow and buggy. I'm looking for a performance solution > here, not a crumb to throw to people with space problems. Well, the right solution is to fix the msdosfs to have a decent performance in the cases needed and to bug davidg & dyson to implement swapping on any random vnode... > Can you be more explicit about "dislikes overlapping slices"? If it's > just a case of some sanity code, I could use a different slice type and > special case the tests. If it's more complex, a brief explanation > and a 'look here for details' would be fine. More as an architectural principle... It's really bde's code, so you'd better ask him. > > Isn't there some static gunk in these files that we shouldn't write ? > > I belive that if you mess with the administrative structures windows > > will barf. > > I have a virgin 386spart.par here for reference. Most of the file is full > of 0x6c (vigin sector filler), except for two regions 0x200 long at the > beginning and end which have every fourth byte incrementing. It looks like > this (custom hexdump output, sorry 8) : > > 1401400: 6d 6c 6c 6c 6e 6c 6c 6c - 6f 6c 6c 6c 68 6c 6c 6c mlllnlllolllhlll > 1401410: 69 6c 6c 6c 6a 6c 6c 6c - 6b 6c 6c 6c 64 6c 6c 6c illljlllkllldlll > 1401420: 65 6c 6c 6c 66 6c 6c 6c - 67 6c 6c 6c 60 6c 6c 6c elllflllglll`lll > 1401430: 61 6c 6c 6c 62 6c 6c 6c - 63 6c 6c 6c 7c 6c 6c 6c alllblllclll|lll > ... > 14015c0: 1d 6c 6c 6c 1e 6c 6c 6c - 1f 6c 6c 6c 18 6c 6c 6c .lll.lll.lll.lll > 14015d0: 19 6c 6c 6c 1a 6c 6c 6c - 1b 6c 6c 6c 14 6c 6c 6c .lll.lll.lll.lll > 14015e0: 15 6c 6c 6c 16 6c 6c 6c - 17 6c 6c 6c 10 6c 6c 6c .lll.lll.lll.lll > 14015f0: 11 6c 6c 6c 12 6c 6c 6c - 13 6c 6c 6c ec 6c 6c 6c .lll.lll.lll.lll > > The first one is at 0x1600, the file ends at 0x1402000, which doesn't > make any sense to me yet but I'm sure something may click 8) the size ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9043.821043381>