Re: memstick.img is bloated with 7% 2K blocks of nulls
On Tue, 15 Feb 2011 01:19:45 +0100
Julian H. Stacey j...@berklix.com wrote:
Could author p...@freebsd.org cc'd (or someone else if they are clear)
please explain what cmdline is ?
Possibly commit an appended // comment after int cmdline = 0;
(in line 76 of 8.1 current src/sbin/mdconfig/mdconfig.c) wgat it's for ?
(cmdline seems in most places to maybe be an enum { 1
2 3 } for { a d l } alternate forms of command mdconfig,
... yet case 'd': sets cmdline = 3 not 2 ?
( 't' 'f' sets cmdline=2 ; not 1.Puzzling.
It's simply a state machine to ensure that mutually exclusive options
aren't used together. See the manpage; it's pretty clear from it that
only certain combinations of options are allowed.
--
Gary Jennejohn
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: memstick.img is bloated with 7% 2K blocks of nulls
Gary Jennejohn wrote:
On Tue, 15 Feb 2011 01:19:45 +0100
Julian H. Stacey j...@berklix.com wrote:
Could author p...@freebsd.org cc'd (or someone else if they are clear)
please explain what cmdline is ?
Possibly commit an appended // comment after int cmdline = 0;
(in line 76 of 8.1 current src/sbin/mdconfig/mdconfig.c) wgat it's for ?
(cmdline seems in most places to maybe be an enum { 1
2 3 } for { a d l } alternate forms of command mdconfig,
... yet case 'd': sets cmdline = 3 not 2 ?
( 't' 'f' sets cmdline=2 ; not 1.Puzzling.
It's simply a state machine to ensure that mutually exclusive options
aren't used together.
I'd wondered that, but
... yet case 'd': sets cmdline = 3 not 2 ?
ie both case 'd': case 'l': cmdline = 3;
which implies:
Either a mistake in the code there,
Or cmdline not a state table of 1,2,3 for the 3 alternate
invocations 'a', 'd', 'l' shown in man mdconfig usage().
See the manpage; it's pretty clear from it that
only certain combinations of options are allowed.
Agreed.
But cmdline doesnt seem to be [just] doing that,
ay least not doing case a d l = 1 2 3, else cmdline usage would be
about as in my diff appended.
So is cmdline is doing something else ? What ?
*** mdconfig.c Tue Feb 15 18:05:56 2011
--- mdconfig_jhs.c Tue Feb 15 19:05:59 2011
***
*** 74,79
--- 74,86
int ch, fd, i, vflag;
char *p;
int cmdline = 0;
+ /* JHS: Assume cmdline is to indicate 1 of the 3 states shown in usage() ?,
eg:
+ * 1 usage: mdconfig -a -t type [-n] [-o [no]option] ... [-f file]\n
+ * [-s size] [-S sectorsize] [-u unit]\n
+ * [-x sectors/track] [-y heads/cyl]\n
+ * 2mdconfig -d -u unit [-o [no]force]\n
+ * 3mdconfig -l [-v] [-n] [-u unit]\n);
+ */
char *mdunit;
bzero(mdio, sizeof(mdio));
***
*** 98,104
usage();
action = DETACH;
mdio.md_options = MD_AUTOUNIT;
! cmdline = 3;
break;
case 'l':
if (cmdline != 0)
--- 105,111
usage();
action = DETACH;
mdio.md_options = MD_AUTOUNIT;
! cmdline = 2;// JHS: was 3
break;
case 'l':
if (cmdline != 0)
***
*** 128,134
} else {
usage();
}
! cmdline=2;
break;
case 'f':
if (cmdline == 0) {
--- 135,141
} else {
usage();
}
! // JHS: cmdline=2;
break;
case 'f':
if (cmdline == 0) {
***
*** 139,147
/* Imply ``-t vnode'' */
mdio.md_type = MD_VNODE;
mdio.md_options = MD_CLUSTER | MD_AUTOUNIT |
MD_COMPRESS;
! cmdline = 2;
}
! if (cmdline != 2)
usage();
if (realpath(optarg, mdio.md_file) == NULL) {
err(1, could not find full path for %s,
--- 146,154
/* Imply ``-t vnode'' */
mdio.md_type = MD_VNODE;
mdio.md_options = MD_CLUSTER | MD_AUTOUNIT |
MD_COMPRESS;
! // JHS: cmdline = 2;
}
! if (cmdline != 1) // JHS: was 2
usage();
if (realpath(optarg, mdio.md_file) == NULL) {
err(1, could not find full path for %s,
***
*** 200,206
errx(1, Unknown option: %s., optarg);
break;
case 'S':
! if (cmdline != 2)
usage();
mdio.md_sectorsize = strtoul(optarg, p, 0);
break;
--- 207,213
errx(1, Unknown option: %s., optarg);
break;
case 'S':
! if (cmdline != 1) // JHS: Was 2
usage();
mdio.md_sectorsize = strtoul(optarg, p, 0);
break;
***
*** 214,222
/* Imply ``-t swap'' */
mdio.md_type =
Re: memstick.img is bloated with 7% 2K blocks of nulls
But from the manual page:
-f file
Filename to use for the vnode type memory disk. Options -a
and -t vnode are implied if not specified.
So if you specify -f then you get -t vnode automatically.
Ah yes. Reading src/sbin/mdconfig/mdconfig.c with your mdconfig
-a -f mfsroot it seems the manual correctly represents the code
... except I'm lost what the purpose of cmdline is ?
( BTW I was wrong re:
I suspect -t default is malloc, though manual doesnt say that
'f' actually follows with: mdio.md_type = MD_VNODE; )
Could author p...@freebsd.org cc'd (or someone else if they are clear)
please explain what cmdline is ?
Possibly commit an appended // comment after int cmdline = 0;
(in line 76 of 8.1 current src/sbin/mdconfig/mdconfig.c) wgat it's for ?
(cmdline seems in most places to maybe be an enum { 1
2 3 } for { a d l } alternate forms of command mdconfig,
... yet case 'd': sets cmdline = 3 not 2 ?
( 't' 'f' sets cmdline=2 ; not 1.Puzzling.
Cheers,
Julian
--
Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
Mail plain text; Not quoted-printable, Not HTML, Not base 64.
Reply below text sections not at top, to avoid breaking cumulative context.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: memstick.img is bloated with 7% 2K blocks of nulls
Bruce Cran wrote: On Sat, 12 Feb 2011 01:54:58 +0100 Julian H. Stacey j...@berklix.com wrote: -O filesystem-type Use 1 to specify that a UFS1 format file system be built; use 2 to specify that a UFS2 format file system be built. The default format is UFS2. If anyone fancies looking deeper, please do :-) I checked with dumpfs that memstick.img is UFS1. Also, mounting /dev/md0 confuses the kernel into ultimately panic'ing, since /dev/md0a is the proper slice. I'm suprised it mounts. Not suprised it crashes. For the mfsroot.gz file from the CD ISOs: # mdconfig -a -f mfsroot md0 # mount /dev/md0a /mnt # ls /mnt ls: /mnt: Bad file descriptor # cd /mnt cd: /mnt: Not a directory # vim /mnt panic: ffs_read: type 0 It's not so obvious but in man mdconfig, there's no [] around -t type, I read that as -t something is mandatory, (though it starts without for you ... I suspect -t default is malloc, though manual doesnt say that, but look what manual says re. malloc ... panic ). I use -t vnode, which doesn't crash here on 8.1-RELEASE i686: mdconfig -a -t vnode -f FreeBSD-8.2-RC3-amd64-memstick.img mount /dev/md0a /mnt cd /mnt tar cf - . | ( cd /pri/FreeBSD/releases/amd64/ISO-IMAGES/8.2\ /FreeBSD-8.2-RC3-amd64-memstick tar xf - ) dumpfs /dev/md0a # UFS1 mdconfig -a -t vnode -f FreeBSD-8.2-RC3-amd64-livefs.iso mount -t cd9660 /dev/md1 /mnt1 cd /mnt1 tar cf - . | ( cd /pri/FreeBSD/releases/amd64/ISO-IMAGES/8.2\ /FreeBSD-8.2-RC3-amd64-livefs tar xf - ) mdconfig -a -t vnode -f FreeBSD-8.2-RC3-amd64-disc1.iso xs mount -t cd9660 /dev/md2 /mnt2 cd /mnt2 tar cf - . | ( cd /pri/FreeBSD/releases/amd64/ISO-IMAGES/8.2\ /FreeBSD-8.2-RC3-amd64-disc1 tar xf - ) cd / ; umount /mnt2 ; umount /mnt1 ; umount /mnt mdconfig -d -u 2 ; mdconfig -d -u 1 ; mdconfig -d -u 0 Analysing sizes: ls -l 723834880 FreeBSD-8.2-RC3-amd64-disc1.iso 348796928 FreeBSD-8.2-RC3-amd64-livefs.iso 1087467520 FreeBSD-8.2-RC3-amd64-memstick.img cd /pri/FreeBSD/releases/amd64/ISO-IMAGES/8.2 ; du -s -k /mnt* * 988708 /mnt# memstick.img 985807 /mnt1 # livefs.iso 705444 /mnt2 # disc1.iso 999340 FreeBSD-8.2-RC3-amd64-memstick 1023032 FreeBSD-8.2-RC3-amd64-livefs 711640 FreeBSD-8.2-RC3-amd64-disc1 df /mnt FilesystemSizeUsed Avail Capacity Mounted on /dev/md0a 1.1G1.0G-14M 101%/mnt umount /mnt ; tunefs -m 0 /dev/md0a tunefs: minimum percentage of free space changes from 8% to 0% tunefs: should optimize for space with minfree 8% df /dev/md0a Filesystem SizeUsed Avail Capacity Mounted on /dev/md0a1.1G1.0G 73M93% cd /pri/FreeBSD/releases/amd64/ISO-IMAGES/8.2 ; /bin/pwd mount | grep /usra /dev/ad4s4e on /usra (ufs, NFS exported, local, soft-updates) dumpfs /dev/ad4s4e | head -1# UFS2 Note du on UFS1 stick (988708) is near the same as tree copied by tar to UFS2 hard disc (999340), so its not the differerence between UFS1 UFS2 that wastes the space (though good guess thanks for suggesting it pushed me to investigate more :-) We are distributing 7% null space: Mainly because the file system is too big. We probably don't need 7% free space on stick just to install or repair, though that might be useful (if slow) for demos ) + Also each file will have unused bytes at end, (but so will livefs.iso have padding per file not near so bloated, albeit probably some other fragment size. Per my first post: 2K blocks of nulls. FreeBSD-8.2-RC3-i386-disc1.iso:565 FreeBSD-8.2-RC3-i386-livefs.iso: 905 FreeBSD-8.2-RC3-i386-memstick.img: 34521 As a sample test of what makefs produces: makefs /tmp/bla /usr/share Extent size set to 8192 block size 8192, fragment size 1024 du -s -k /usr/share# 54 108 ls -l /tmp/bla # 54 927 360 df /tmp/bla Filesystem SizeUsed Avail Capacity Mounted on /dev/ad0s2e520M 55M423M12%/tmp # PS Note df lies 520M - some bug as not a node ? mdconfig -a -t vnode -f /tmp/bla# md2 df /dev/md2* Filesystem1K-blocks UsedAvail Capacity /dev/md2 51175 48723-1642 103% tunefs -m 2 /dev/md2
Re: memstick.img is bloated with 7% 2K blocks of nulls
On Sat, 12 Feb 2011 17:56:08 +0100 Julian H. Stacey j...@berklix.com wrote: It's not so obvious but in man mdconfig, there's no [] around -t type, I read that as -t something is mandatory, (though it starts without for you ... I suspect -t default is malloc, though manual doesnt say that, but look what manual says re. malloc ... panic ). But from the manual page: -f file Filename to use for the vnode type memory disk. Options -a and -t vnode are implied if not specified. So if you specify -f then you get -t vnode automatically. -- Bruce Cran ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: memstick.img is bloated with 7% 2K blocks of nulls
On Feb 11, 2011, at 11:09 AM, Julian H. Stacey wrote: memstick.img wastes 7% with 2K blocks of nulls. shown by: 8f -b 0 -n 2048 -l -f Fr* http://berklix.com/~jhs/src/bsd/jhs/bin/public/8f/ 8f.c 8f.1 ... The CD DVD images are not nearly so wasteful, see above. As near 1G ( 959467520 FreeBSD-8.2-RC3-i386-memstick.img ) it will soon not fit on 1G sticks. There is a big difference between laying out a read-only filesystem and laying out a read-write disk image. CD/DVD writers do pack file contents one after the other on the image. The current UFS code is designed to leave enough slack space to support future file writes. The strategy used by libarchive's recent ISO writer is to concatenate the file bodies into a temp file (with minimal padding between entries to meet alignment requirements) while storing directory information in memory. The final output then consists of the directory information followed by the concatenated file bodies. I suspect a similar strategy could be used to lay out and write a read-only optimized UFS image. A few folks have asked about a UFS writer for libarchive; I think it's probably feasible but I doubt very much of the existing UFS code can be recycled for such a project. Alternatively, of course, is there any way to use isofs instead of ufs for memstick.img? Tim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: memstick.img is bloated with 7% 2K blocks of nulls
On Sat, 12 Feb 2011, Tim Kientzle wrote: Alternatively, of course, is there any way to use isofs instead of ufs for memstick.img? Devin Teske's DruidBSD (http://druidbsd.sourceforge.net/) uses the same image for CD, hard disk, or memstick. I don't know the technical details. (VirtualBox didn't like it, but maybe it's a trivial fix.) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: memstick.img is bloated with 7% 2K blocks of nulls
On 13/02/2011, at 8:45, Warren Block wrote: On Sat, 12 Feb 2011, Tim Kientzle wrote: Alternatively, of course, is there any way to use isofs instead of ufs for memstick.img? Devin Teske's DruidBSD (http://druidbsd.sourceforge.net/) uses the same image for CD, hard disk, or memstick. I don't know the technical details. (VirtualBox didn't like it, but maybe it's a trivial fix.) I would guess it uses ISOLinux plus some voodoo hackery the same as various Linux distros which do the same trick. For work I have made a FAT32 USB stick which uses syslinux to load an MFS containing the loader kernel and sysinstall then reads the install files off FAT32. I did it this way so that people using it could edit the configuration file without needing a BSD box handy. In theory the loader can read off FAT32 so the kernel could go onto the flash drive too, however I couldn't get it to work :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: memstick.img is bloated with 7% 2K blocks of nulls
Tim Kientzle wrote: The current UFS code is designed to leave enough slack space to support future file writes. What if you turned the knob all the way down and had just one cylinder group? I assume that newfs would need to be fixed to allow this, but would anything break? The current limits are also wasteful for normal read/write filesystems with large files. Too many cylinder groups, too many inodes, block/frag size too small, etc... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: memstick.img is bloated with 7% 2K blocks of nulls
Tim Kientzle t...@kientzle.com wrote: The strategy used by libarchive's recent ISO writer is to concatenate the file bodies into a temp file (with minimal padding between entries to meet alignment requirements) while storing directory information in memory. The final output then consists of the directory information followed by the concatenated file bodies. I suspect a similar strategy could be used to lay out and write a read-only optimized UFS image ... I think it's probably feasible but I doubt very much of the existing UFS code can be recycled for such a project. There was at one time a capability in mkfs(8) -- which no longer even exists as a separate entity, having been absorbed into newfs(8) -- to pre-populate the filesystem with specified content. Dunno if it was ever in any BSD release -- it's not mentioned in the 4.2BSD-derived SunOS 4.1.1 manpage -- so I may be remembering it from Bell Labs 6th edition on the PDP-11. The code to collect and write all of an existing filesystem's directories, followed by all of its files, exists in dump(8). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: memstick.img is bloated with 7% 2K blocks of nulls
On 2/12/11 7:45 PM, per...@pluto.rain.com wrote: Tim Kientzlet...@kientzle.com wrote: The strategy used by libarchive's recent ISO writer is to concatenate the file bodies into a temp file (with minimal padding between entries to meet alignment requirements) while storing directory information in memory. The final output then consists of the directory information followed by the concatenated file bodies. I suspect a similar strategy could be used to lay out and write a read-only optimized UFS image ... I think it's probably feasible but I doubt very much of the existing UFS code can be recycled for such a project. There was at one time a capability in mkfs(8) -- which no longer even exists as a separate entity, having been absorbed into newfs(8) -- to pre-populate the filesystem with specified content. Dunno if it was ever in any BSD release -- it's not mentioned in the 4.2BSD-derived SunOS 4.1.1 manpage -- so I may be remembering it from Bell Labs 6th edition on the PDP-11. man makefs The code to collect and write all of an existing filesystem's directories, followed by all of its files, exists in dump(8). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
memstick.img is bloated with 7% 2K blocks of nulls
memstick.img wastes 7% with 2K blocks of nulls. shown by: 8f -b 0 -n 2048 -l -f Fr* http://berklix.com/~jhs/src/bsd/jhs/bin/public/8f/ 8f.c 8f.1 FreeBSD-8.1-RELEASE-amd64-bootonly.iso:543 FreeBSD-8.1-RELEASE-amd64-disc1.iso: 543 FreeBSD-8.1-RELEASE-amd64-dvd1.iso: 1125 FreeBSD-8.1-RELEASE-amd64-livefs.iso: 1109 FreeBSD-8.1-RELEASE-amd64-memstick.img: 38722 FreeBSD-8.1-RELEASE-i386-bootonly.iso: 511 FreeBSD-8.1-RELEASE-i386-disc1.iso:511 FreeBSD-8.1-RELEASE-i386-dvd1.iso: 865 FreeBSD-8.1-RELEASE-i386-dvd1.iso: 893 FreeBSD-8.1-RELEASE-i386-livefs.iso: 850 FreeBSD-8.1-RELEASE-i386-memstick.img: 34066 FreeBSD-8.2-RC3-amd64-bootonly.iso:594 FreeBSD-8.2-RC3-amd64-disc1.iso: 594 FreeBSD-8.2-RC3-amd64-dvd1.iso: 1167 FreeBSD-8.2-RC3-amd64-livefs.iso: 1166 FreeBSD-8.2-RC3-amd64-memstick.img: 39216 FreeBSD-8.2-RC3-i386-bootonly.iso: 565 FreeBSD-8.2-RC3-i386-disc1.iso:565 FreeBSD-8.2-RC3-i386-dvd1.iso: 906 FreeBSD-8.2-RC3-i386-livefs.iso: 905 FreeBSD-8.2-RC3-i386-memstick.img: 34521 It's not just one big block of trailing nulls. od -c FreeBSD-8.2-RC3-i386-memstick.img tmp.od ; tail tmp.od 7114017760@ 244 377 344 Q \b * 325 \t 333 y ` ' \n W 711402 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 711405 05 - 02 = 03 = 0x3000 = 12288 It's a lot of bursts of null blocks, seen by either: grep -n '^*' tmp.od 8f -f -c -b 0 -n 2048 FreeBSD-8.2-RC3-i386-memstick.img The CD DVD images are not nearly so wasteful, see above. As near 1G ( 959467520 FreeBSD-8.2-RC3-i386-memstick.img ) it will soon not fit on 1G sticks. If its not easy for someone to find trim, xz compression would at least save 27% of transmission bandwidth, ( dc 702447528 100 * 959467520 / p 73 ) a much higher % than DVD that also uses compression. PS I sent this to hackers@ rather than re@ as I imagine re@ are busy with more urgent matters at present :-) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not quoted-printable, Not HTML, Not base 64. Reply below text sections not at top, to avoid breaking cumulative context. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: memstick.img is bloated with 7% 2K blocks of nulls
On Fri, 11 Feb 2011 20:09:30 +0100 Julian H. Stacey j...@berklix.com wrote: memstick.img wastes 7% with 2K blocks of nulls. Could this be due to using UFS1 instead of UFS2? On a related note, at some point the release scripts should be updated to use gpart instead of fdisk/bsdlabel. -- Bruce Cran ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: memstick.img is bloated with 7% 2K blocks of nulls
Bruce Cran wrote:
On Fri, 11 Feb 2011 20:09:30 +0100
Julian H. Stacey j...@berklix.com wrote:
memstick.img wastes 7% with 2K blocks of nulls.
Could this be due to using UFS1 instead of UFS2?
Don't know, Looking:
8.1 /usr/src/release/scripts/make-memstick.sh
man makefs
-t fs-type ... The following file system
types are supported:
ffs BSD fast file system (default).
FFS-specific options
version UFS version. 1 for FFS (default), 2 for UFS2
/usr/src/release/Makefile --
scripts/doFS.sh:
newfs -i ${FSINODE} -o space -m 0 /dev/r${VNDEVICE}c
...
newfs -O1 -b 4096 -f 512 -i ${FSINODE} -o space -m 0 /dev/${MDDEVICE}
man newfs:
-O filesystem-type
Use 1 to specify that a UFS1 format file system be built; use 2
to specify that a UFS2 format file system be built. The default
format is UFS2.
If anyone fancies looking deeper, please do :-)
Cheers,
Julian
--
Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
Mail plain text; Not quoted-printable, Not HTML, Not base 64.
Reply below text sections not at top, to avoid breaking cumulative context.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: memstick.img is bloated with 7% 2K blocks of nulls
On Sat, 12 Feb 2011 01:54:58 +0100 Julian H. Stacey j...@berklix.com wrote: -O filesystem-type Use 1 to specify that a UFS1 format file system be built; use 2 to specify that a UFS2 format file system be built. The default format is UFS2. If anyone fancies looking deeper, please do :-) I checked with dumpfs that memstick.img is UFS1. Also, mounting /dev/md0 confuses the kernel into ultimately panic'ing, since /dev/md0a is the proper slice. For the mfsroot.gz file from the CD ISOs: # mdconfig -a -f mfsroot md0 # mount /dev/md0a /mnt # ls /mnt ls: /mnt: Bad file descriptor # cd /mnt cd: /mnt: Not a directory # vim /mnt panic: ffs_read: type 0 kdb_enter() panic() ffs_read() vn_read dofileread() kern_readv() read() syscallenter() syscall() Xfast_syscall() -- Bruce Cran ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
