Re: Odd df reporting (On Apr 3 snapshot, data copied via 3.8snapshot)
Cool! That seems to have done the trick (April 20, 2006 snapshot): (I)nstall, (U)pgrade, or (S)hell? s # fsck -b32 -f /dev/rwd0d Alternate Superblock Location: 32 ** /dev/rwd0d ** File system is already clean ** Last mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups SUMMARY INFORMATION BAD SALVAGE? [Fyn] y FREE BLK COUNT(S) IN WRONG SUPERBLK SALVAGE? [Fyn] y 9406 files, 8177199 used, 22783126 free (1086 frags, 2847755 blocks, 0.0% fragmentation) UPDATE STANDARD SUPERBLK? [Fyn?] y * FILE SYSTEM WAS MODIFIED * # Thanks, error message cleared! -Whyzzi On 14/04/06, Pedro Martelletto [EMAIL PROTECTED] wrote: Yes, it has a built-in fsck. But you will need to update your kernel too. -p.
Re: Odd df reporting (On Apr 3 snapshot, data copied via 3.8snapshot)
Could I conceivably download the latest snapshot bsd.rd and check that way, rather than upgrading my existing system? On 13/04/06, Pedro Martelletto [EMAIL PROTECTED] wrote: And a fresh kernel too :-)
Re: Odd df reporting (On Apr 3 snapshot, data copied via 3.8snapshot)
On Sat, 8 Apr 2006, Whyzzi wrote: To be on the safe side, run a 3.8 fsck. Easiest way to do that is copy a 3.8 bsd.rd and boot that. Go to the shell and run fsck -f. -Otto Done. Followed http://www.openbsd.org/faq/faq4.html#bsd.rd part of the FAQ, and ripped the 3.8 bsd.rd from the usa.openbsd.org server. Just for info, the bsd.38.rd reports the same df as the others... Ok, this is strange: =-=-=-=-=-=-=-=-=- # fsck /dev/rwd0d ** /dev/rwd0d ** File system is clean; not checking # fsck -f /dev/rwd0d ** /dev/rwd0d ** File system is already clean cannot alloc 4294966928 bytes for inphead # fsck -f /dev/wd0d ** /dev/wd0d ** File system is already clean cannot alloc 4294966928 bytes for inphead # =-=-=-=-=-=-=-=-=- I hope that helps some.. If there is anything else you'd like from this box just let me know! Hmm, have to think about this maybe the alternative super blocks are ok, but it's becoming tricky. -Otto
Re: Odd df reporting (On Apr 3 snapshot, data copied via 3.8snapshot)
It would be wise to actually force the checking by specifying -f. -p.
Re: Odd df reporting (On Apr 3 snapshot, data copied via 3.8snapshot)
On Fri, 7 Apr 2006, Whyzzi wrote: On 07/04/06, Otto Moerbeek [EMAIL PROTECTED] wrote: On Thu, 6 Apr 2006, Whyzzi wrote: Yeah! that is the thing I didn't do! Run fsck against the affected partition! Anyways, as per your questions: I copied the with cp, eg: # cd /mnt/wd1a # cp -R Anime /mnt/wd2d Here are the raw df output from the current snapshot kernel [brought to you by the wonders of OpenSSH]: # df Filesystem 512-blocks Used Avail Capacity Mounted on /dev/wd0a 18572172 1062820 16580744 6%/ /dev/wd0d123841300 4215514788 197101744 14535%/mnt/wd0d /dev/wd0e123841300 13434788 10421444811%/mnt/wd0e /dev/wd0f212356232 66929816 13480860833%/mnt/wd0f # I had torrent'd the Olive OpenBSD live cd awhile back that was a December? -stable 3.8 (I think), could I use that to run fsck against the affected partition? That would be easier to do than to hookup the 40gig that contained the Dec snapshot (I don't have a copy of either 3.8/3.9 -release available, but I will make one and install it if you want me to). The Olive CD will probably do, although booting a 3.8 kernel from the boot prompt should work as well; just copy the 3.8 kernel to your root as bsd38 and type boot bsd38 at the boot prompt. Cool. Done. I used ftp to grab the 3.8 release kernel from a local mirror. I booted single user mode cause I didn't want my services spewing at me due to kernel differences. Below are the results: =-=-=-=-=-=-=-=-=-=-=-=- boot boot /bsd.38 -s /** SNIP -- cause I copied everything by hand **/ Enter pathname or RETURN for shell: Terminal type? vt220 # dh -h Filesystem Size Used Avail Capacity Mounted on root_device 8.9G 524M 7.9G 6% / # mount /dev/wd0d /mnt/wd0d # df Filesystem 512-blocks Used Avail Capacity Mounted on root_device 185721271073632 16569932 6%/ /dev/wd0d 123841300 4215514788 197101744 14535%/dev/wd0d =-=-=-=-=-=-=-=-=-=-=-=- Interesting. No difference whatsoever. And because I am a (l)user, I am not going to even try to theorize what happened and why. The only thing I will say is that each directory I copied - there were five, all contained literally more than 10Gigabytes (usually more) of useless data each (ok the mp3 collection isn't so useless). This might be reproduce-able by creating 20 or so 500MB files and stuffing them into various subdirectories, totalling 10Gb in one directory. copy that 5 times by giving the same directory a different name. Then take a look at the drive stats via df. Just remember that in my case the destination partition was mounted sync. Is there anything you would like to have done - or can I use the 3.9 snapshot and run the fsck? Cheers, thanks! To be on the safe side, run a 3.8 fsck. Easiest way to do that is copy a 3.8 bsd.rd and boot that. Go to the shell and run fsck -f. -Otto
Re: Odd df reporting (On Apr 3 snapshot, data copied via 3.8snapshot)
On 08/04/06, Otto Moerbeek [EMAIL PROTECTED] wrote: On Fri, 7 Apr 2006, Whyzzi wrote: On 07/04/06, Otto Moerbeek [EMAIL PROTECTED] wrote: On Thu, 6 Apr 2006, Whyzzi wrote: Yeah! that is the thing I didn't do! Run fsck against the affected partition! Anyways, as per your questions: I copied the with cp, eg: # cd /mnt/wd1a # cp -R Anime /mnt/wd2d Here are the raw df output from the current snapshot kernel [brought to you by the wonders of OpenSSH]: # df Filesystem 512-blocks Used Avail Capacity Mounted on /dev/wd0a 18572172 1062820 16580744 6%/ /dev/wd0d123841300 4215514788 197101744 14535%/mnt/wd0d /dev/wd0e123841300 13434788 10421444811%/mnt/wd0e /dev/wd0f212356232 66929816 13480860833%/mnt/wd0f # I had torrent'd the Olive OpenBSD live cd awhile back that was a December? -stable 3.8 (I think), could I use that to run fsck against the affected partition? That would be easier to do than to hookup the 40gig that contained the Dec snapshot (I don't have a copy of either 3.8/3.9 -release available, but I will make one and install it if you want me to). The Olive CD will probably do, although booting a 3.8 kernel from the boot prompt should work as well; just copy the 3.8 kernel to your root as bsd38 and type boot bsd38 at the boot prompt. Cool. Done. I used ftp to grab the 3.8 release kernel from a local mirror. I booted single user mode cause I didn't want my services spewing at me due to kernel differences. Below are the results: =-=-=-=-=-=-=-=-=-=-=-=- boot boot /bsd.38 -s /** SNIP -- cause I copied everything by hand **/ Enter pathname or RETURN for shell: Terminal type? vt220 # dh -h Filesystem Size Used Avail Capacity Mounted on root_device 8.9G 524M 7.9G 6% / # mount /dev/wd0d /mnt/wd0d # df Filesystem 512-blocks Used Avail Capacity Mounted on root_device 185721271073632 16569932 6%/ /dev/wd0d 123841300 4215514788 197101744 14535%/dev/wd0d =-=-=-=-=-=-=-=-=-=-=-=- Interesting. No difference whatsoever. And because I am a (l)user, I am not going to even try to theorize what happened and why. The only thing I will say is that each directory I copied - there were five, all contained literally more than 10Gigabytes (usually more) of useless data each (ok the mp3 collection isn't so useless). This might be reproduce-able by creating 20 or so 500MB files and stuffing them into various subdirectories, totalling 10Gb in one directory. copy that 5 times by giving the same directory a different name. Then take a look at the drive stats via df. Just remember that in my case the destination partition was mounted sync. Is there anything you would like to have done - or can I use the 3.9 snapshot and run the fsck? Cheers, thanks! To be on the safe side, run a 3.8 fsck. Easiest way to do that is copy a 3.8 bsd.rd and boot that. Go to the shell and run fsck -f. -Otto Done. Followed http://www.openbsd.org/faq/faq4.html#bsd.rd part of the FAQ, and ripped the 3.8 bsd.rd from the usa.openbsd.org server. Just for info, the bsd.38.rd reports the same df as the others... Ok, this is strange: =-=-=-=-=-=-=-=-=- # fsck /dev/rwd0d ** /dev/rwd0d ** File system is clean; not checking # fsck -f /dev/rwd0d ** /dev/rwd0d ** File system is already clean cannot alloc 4294966928 bytes for inphead # fsck -f /dev/wd0d ** /dev/wd0d ** File system is already clean cannot alloc 4294966928 bytes for inphead # =-=-=-=-=-=-=-=-=- I hope that helps some.. If there is anything else you'd like from this box just let me know!
Re: Odd df reporting (On Apr 3 snapshot, data copied via 3.8snapshot)
Oh - and admittedly, one of the directories in the problem partition has over smaller 5000+ files in it: =-=-=-=-=-=-=- # ls -al | wc -l 5131 # # ls -al total 468 drwxrwxr-x 7 name name 512 Apr 4 21:27 . drwxrwxr-x 3 name name 512 Apr 4 21:11 .. drwxr-xr-x 2 name name 88064 Apr 4 21:27 Folder drwxr-xr-x 2 name name 512 Apr 4 21:27 conversations drwxrwxr-x 2 name name 140288 Apr 4 21:25 graphics drwxr-xr-x 4 name name 512 Apr 4 21:27 shorts drwxrwxr-x 8 name name 512 Apr 4 21:23 lists # =-=-=-=-=-=-=- Cheers! On 08/04/06, Whyzzi [EMAIL PROTECTED] wrote: On 08/04/06, Otto Moerbeek [EMAIL PROTECTED] wrote: On Fri, 7 Apr 2006, Whyzzi wrote: On 07/04/06, Otto Moerbeek [EMAIL PROTECTED] wrote: On Thu, 6 Apr 2006, Whyzzi wrote: Yeah! that is the thing I didn't do! Run fsck against the affected partition! Anyways, as per your questions: I copied the with cp, eg: # cd /mnt/wd1a # cp -R Anime /mnt/wd2d Here are the raw df output from the current snapshot kernel [brought to you by the wonders of OpenSSH]: # df Filesystem 512-blocks Used Avail Capacity Mounted on /dev/wd0a 18572172 1062820 16580744 6%/ /dev/wd0d123841300 4215514788 197101744 14535%/mnt/wd0d /dev/wd0e123841300 13434788 10421444811%/mnt/wd0e /dev/wd0f212356232 66929816 13480860833%/mnt/wd0f # I had torrent'd the Olive OpenBSD live cd awhile back that was a December? -stable 3.8 (I think), could I use that to run fsck against the affected partition? That would be easier to do than to hookup the 40gig that contained the Dec snapshot (I don't have a copy of either 3.8/3.9 -release available, but I will make one and install it if you want me to). The Olive CD will probably do, although booting a 3.8 kernel from the boot prompt should work as well; just copy the 3.8 kernel to your root as bsd38 and type boot bsd38 at the boot prompt. Cool. Done. I used ftp to grab the 3.8 release kernel from a local mirror. I booted single user mode cause I didn't want my services spewing at me due to kernel differences. Below are the results: =-=-=-=-=-=-=-=-=-=-=-=- boot boot /bsd.38 -s /** SNIP -- cause I copied everything by hand **/ Enter pathname or RETURN for shell: Terminal type? vt220 # dh -h Filesystem Size Used Avail Capacity Mounted on root_device 8.9G 524M 7.9G 6% / # mount /dev/wd0d /mnt/wd0d # df Filesystem 512-blocks Used Avail Capacity Mounted on root_device 185721271073632 16569932 6%/ /dev/wd0d 123841300 4215514788 197101744 14535%/dev/wd0d =-=-=-=-=-=-=-=-=-=-=-=- Interesting. No difference whatsoever. And because I am a (l)user, I am not going to even try to theorize what happened and why. The only thing I will say is that each directory I copied - there were five, all contained literally more than 10Gigabytes (usually more) of useless data each (ok the mp3 collection isn't so useless). This might be reproduce-able by creating 20 or so 500MB files and stuffing them into various subdirectories, totalling 10Gb in one directory. copy that 5 times by giving the same directory a different name. Then take a look at the drive stats via df. Just remember that in my case the destination partition was mounted sync. Is there anything you would like to have done - or can I use the 3.9 snapshot and run the fsck? Cheers, thanks! To be on the safe side, run a 3.8 fsck. Easiest way to do that is copy a 3.8 bsd.rd and boot that. Go to the shell and run fsck -f. -Otto Done. Followed http://www.openbsd.org/faq/faq4.html#bsd.rd part of the FAQ, and ripped the 3.8 bsd.rd from the usa.openbsd.org server. Just for info, the bsd.38.rd reports the same df as the others... Ok, this is strange: =-=-=-=-=-=-=-=-=- # fsck /dev/rwd0d ** /dev/rwd0d ** File system is clean; not checking # fsck -f /dev/rwd0d ** /dev/rwd0d ** File system is already clean cannot alloc 4294966928 bytes for inphead # fsck -f /dev/wd0d ** /dev/wd0d ** File system is already clean cannot alloc 4294966928 bytes for inphead # =-=-=-=-=-=-=-=-=- I hope that helps some.. If there is anything else you'd like from this box just let me know! -- I know too much and yet not enough
Re: Odd df reporting (On Apr 3 snapshot, data copied via 3.8snapshot)
On Thu, 6 Apr 2006, Whyzzi wrote: Yeah! that is the thing I didn't do! Run fsck against the affected partition! Anyways, as per your questions: I copied the with cp, eg: # cd /mnt/wd1a # cp -R Anime /mnt/wd2d Here are the raw df output from the current snapshot kernel [brought to you by the wonders of OpenSSH]: # df Filesystem 512-blocks Used Avail Capacity Mounted on /dev/wd0a 18572172 1062820 16580744 6%/ /dev/wd0d123841300 4215514788 197101744 14535%/mnt/wd0d /dev/wd0e123841300 13434788 10421444811%/mnt/wd0e /dev/wd0f212356232 66929816 13480860833%/mnt/wd0f # I had torrent'd the Olive OpenBSD live cd awhile back that was a December? -stable 3.8 (I think), could I use that to run fsck against the affected partition? That would be easier to do than to hookup the 40gig that contained the Dec snapshot (I don't have a copy of either 3.8/3.9 -release available, but I will make one and install it if you want me to). The Olive CD will probably do, although booting a 3.8 kernel from the boot prompt should work as well; just copy the 3.8 kernel to your root as bsd38 and type boot bsd38 at the boot prompt. -Otto Cheers, thanks for the reply!! On 06/04/06, Otto Moerbeek [EMAIL PROTECTED] wrote: On Wed, 5 Apr 2006, Whyzzi wrote: I've had a strange occurance I'd like to report, in using df -h, but the circumstances that brought about this condition are somewhat unusual, so I really don't know if it is anything to be concerned about. This might also have already been fixed, as I do not follow tech/src Background: I have setup a home based samba media file server, originally running 3.8; a snapshot from Dec. The files on this server was split between 2 drives, a decrepid 30gig IBM/Hitachi, and a Maxtor 40gig. Pulled the plug on the two drives, and connected the a Seagate 250Gig IDE HD. (primary master IDE). Installed the April 3rd snapshot on it via dvdrw. Gave root 9Gig at the front of the drive, swap 1gig, created 2 60gig partitions, and 100gig, all with pre-setup mount points (df, disklabel, fstab, dmesg included @ end). Disconnected dvdrw, connected the 250Gig to the secondary IDE master, and booted into the older 3.8 snapshot. Mounted one of the partitions I created in 3.9, and proceded to copy the files over (yeah, 50+gigs over UDMA33 without softdep can take quite some time to copy on a P3 700). When that was finally done, and since I had the root of 3.9 accessible, I modified 3.9's fstab to include softdep, modified pf, modified rc/rc.conf, plus startup config stuff. Then I turned off the PC removed the 30 40gig drives, mounted the 250gig to the case - and reconnected it to the primary ide interface on the mainboard, and reconnected the dvdrw drive. Originally, when I had booted up, df was reporting (no snapshot taken) no additional space used by the partition (ie freshly formated, even though I had copied stuff there in 3.8). I've since moved the directories I wanted to move, and now df is reporting wayy over the size limit. So before I move the last of the information around reformat the partition to return accurate results, I thought I'd share with the list what I am seeing: ## df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/wd0a 8.9G519M7.9G 6%/ /dev/wd0d 59.1G8.0T 94.0G 14535%/mnt/wd0d /dev/wd0e 59.1G6.4G 49.7G11%/mnt/wd0e /dev/wd0f 101G 31.7G 64.4G33%/mnt/wd0f How did you copy the files? There have been some changes wrt filesystems. Too see if they have anything to do with it, please try the following: - run a 3.9 (or 3.8 if you do not have that) release kernel, and check the numbers. - umount the filesystem and run fsck -f on /dev/wd0d - remount and check nunbers - go back to the snap kernel and repeat. oh and report the output of df without -h, I like to see the raw numbers. -Otto ## disklabel wd0 # Inside MBR partition 3: type A6 start 63 size 488392002 # /dev/rwd0c: type: ESDI disk: ESDI/IDE disk label: ST3250823A flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 16383 total sectors: 488397168 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 16 partitions: # sizeoffset fstype [fsize bsize cpg] a: 1887473763 4.2BSD 2048 16384 328 # Cyl 0*- 18724 b: 2097648 18874800swap # Cyl 18725 - 20805 c: 488397168 0 unused 0 0 # Cyl 0 -484520 d: 125828640
Re: Odd df reporting (On Apr 3 snapshot, data copied via 3.8snapshot)
On 07/04/06, Otto Moerbeek [EMAIL PROTECTED] wrote: On Thu, 6 Apr 2006, Whyzzi wrote: Yeah! that is the thing I didn't do! Run fsck against the affected partition! Anyways, as per your questions: I copied the with cp, eg: # cd /mnt/wd1a # cp -R Anime /mnt/wd2d Here are the raw df output from the current snapshot kernel [brought to you by the wonders of OpenSSH]: # df Filesystem 512-blocks Used Avail Capacity Mounted on /dev/wd0a 18572172 1062820 16580744 6%/ /dev/wd0d123841300 4215514788 197101744 14535%/mnt/wd0d /dev/wd0e123841300 13434788 10421444811%/mnt/wd0e /dev/wd0f212356232 66929816 13480860833%/mnt/wd0f # I had torrent'd the Olive OpenBSD live cd awhile back that was a December? -stable 3.8 (I think), could I use that to run fsck against the affected partition? That would be easier to do than to hookup the 40gig that contained the Dec snapshot (I don't have a copy of either 3.8/3.9 -release available, but I will make one and install it if you want me to). The Olive CD will probably do, although booting a 3.8 kernel from the boot prompt should work as well; just copy the 3.8 kernel to your root as bsd38 and type boot bsd38 at the boot prompt. Cool. Done. I used ftp to grab the 3.8 release kernel from a local mirror. I booted single user mode cause I didn't want my services spewing at me due to kernel differences. Below are the results: =-=-=-=-=-=-=-=-=-=-=-=- boot boot /bsd.38 -s /** SNIP -- cause I copied everything by hand **/ Enter pathname or RETURN for shell: Terminal type? vt220 # dh -h Filesystem Size Used Avail Capacity Mounted on root_device 8.9G 524M 7.9G 6% / # mount /dev/wd0d /mnt/wd0d # df Filesystem 512-blocks Used Avail Capacity Mounted on root_device 185721271073632 16569932 6%/ /dev/wd0d 123841300 4215514788 197101744 14535%/dev/wd0d =-=-=-=-=-=-=-=-=-=-=-=- Interesting. No difference whatsoever. And because I am a (l)user, I am not going to even try to theorize what happened and why. The only thing I will say is that each directory I copied - there were five, all contained literally more than 10Gigabytes (usually more) of useless data each (ok the mp3 collection isn't so useless). This might be reproduce-able by creating 20 or so 500MB files and stuffing them into various subdirectories, totalling 10Gb in one directory. copy that 5 times by giving the same directory a different name. Then take a look at the drive stats via df. Just remember that in my case the destination partition was mounted sync. Is there anything you would like to have done - or can I use the 3.9 snapshot and run the fsck? Cheers, thanks! Cheers, thanks for the reply!! On 06/04/06, Otto Moerbeek [EMAIL PROTECTED] wrote: On Wed, 5 Apr 2006, Whyzzi wrote: I've had a strange occurance I'd like to report, in using df -h, but the circumstances that brought about this condition are somewhat unusual, so I really don't know if it is anything to be concerned about. This might also have already been fixed, as I do not follow tech/src Background: I have setup a home based samba media file server, originally running 3.8; a snapshot from Dec. The files on this server was split between 2 drives, a decrepid 30gig IBM/Hitachi, and a Maxtor 40gig. Pulled the plug on the two drives, and connected the a Seagate 250Gig IDE HD. (primary master IDE). Installed the April 3rd snapshot on it via dvdrw. Gave root 9Gig at the front of the drive, swap 1gig, created 2 60gig partitions, and 100gig, all with pre-setup mount points (df, disklabel, fstab, dmesg included @ end). Disconnected dvdrw, connected the 250Gig to the secondary IDE master, and booted into the older 3.8 snapshot. Mounted one of the partitions I created in 3.9, and proceded to copy the files over (yeah, 50+gigs over UDMA33 without softdep can take quite some time to copy on a P3 700). When that was finally done, and since I had the root of 3.9 accessible, I modified 3.9's fstab to include softdep, modified pf, modified rc/rc.conf, plus startup config stuff. Then I turned off the PC removed the 30 40gig drives, mounted the 250gig to the case - and reconnected it to the primary ide interface on the mainboard, and reconnected the dvdrw drive. Originally, when I had booted up, df was reporting (no snapshot taken) no additional space used by the partition (ie freshly formated, even though I had copied stuff there in 3.8). I've since moved the directories I wanted to move, and now df is reporting wayy over the size limit. So before I move the last of the information around reformat the partition to return accurate results, I thought I'd share with the list what I am seeing: ## df -h
Re: Odd df reporting (On Apr 3 snapshot, data copied via 3.8snapshot)
On Wed, 5 Apr 2006, Whyzzi wrote: I've had a strange occurance I'd like to report, in using df -h, but the circumstances that brought about this condition are somewhat unusual, so I really don't know if it is anything to be concerned about. This might also have already been fixed, as I do not follow tech/src Background: I have setup a home based samba media file server, originally running 3.8; a snapshot from Dec. The files on this server was split between 2 drives, a decrepid 30gig IBM/Hitachi, and a Maxtor 40gig. Pulled the plug on the two drives, and connected the a Seagate 250Gig IDE HD. (primary master IDE). Installed the April 3rd snapshot on it via dvdrw. Gave root 9Gig at the front of the drive, swap 1gig, created 2 60gig partitions, and 100gig, all with pre-setup mount points (df, disklabel, fstab, dmesg included @ end). Disconnected dvdrw, connected the 250Gig to the secondary IDE master, and booted into the older 3.8 snapshot. Mounted one of the partitions I created in 3.9, and proceded to copy the files over (yeah, 50+gigs over UDMA33 without softdep can take quite some time to copy on a P3 700). When that was finally done, and since I had the root of 3.9 accessible, I modified 3.9's fstab to include softdep, modified pf, modified rc/rc.conf, plus startup config stuff. Then I turned off the PC removed the 30 40gig drives, mounted the 250gig to the case - and reconnected it to the primary ide interface on the mainboard, and reconnected the dvdrw drive. Originally, when I had booted up, df was reporting (no snapshot taken) no additional space used by the partition (ie freshly formated, even though I had copied stuff there in 3.8). I've since moved the directories I wanted to move, and now df is reporting wayy over the size limit. So before I move the last of the information around reformat the partition to return accurate results, I thought I'd share with the list what I am seeing: ## df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/wd0a 8.9G519M7.9G 6%/ /dev/wd0d 59.1G8.0T 94.0G 14535%/mnt/wd0d /dev/wd0e 59.1G6.4G 49.7G11%/mnt/wd0e /dev/wd0f 101G 31.7G 64.4G33%/mnt/wd0f How did you copy the files? There have been some changes wrt filesystems. Too see if they have anything to do with it, please try the following: - run a 3.9 (or 3.8 if you do not have that) release kernel, and check the numbers. - umount the filesystem and run fsck -f on /dev/wd0d - remount and check nunbers - go back to the snap kernel and repeat. oh and report the output of df without -h, I like to see the raw numbers. -Otto ## disklabel wd0 # Inside MBR partition 3: type A6 start 63 size 488392002 # /dev/rwd0c: type: ESDI disk: ESDI/IDE disk label: ST3250823A flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 16383 total sectors: 488397168 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 16 partitions: # sizeoffset fstype [fsize bsize cpg] a: 1887473763 4.2BSD 2048 16384 328 # Cyl 0*- 18724 b: 2097648 18874800swap # Cyl 18725 - 20805 c: 488397168 0 unused 0 0 # Cyl 0 -484520 d: 125828640 20972448 4.2BSD 2048 16384 328 # Cyl 20806 -145635 e: 125828640 146801088 4.2BSD 2048 16384 328 # Cyl 145636 -270465 f: 215762337 272629728 4.2BSD 2048 16384 328 # Cyl 270466 -484515* cat /etc/fstab /dev/wd0a / ffs rw 1 1 /dev/wd0d /mnt/wd0d ffs rw,nodev,nosuid,softdep 1 2 /dev/wd0e /mnt/wd0e ffs rw,nodev,nosuid,softdep 1 2 /dev/wd0f /mnt/wd0f ffs rw,nodev,nosuid,softdep 1 2 dmesg OpenBSD 3.9-current (GENERIC) #672: Mon Apr 3 16:15:29 MDT 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium III (GenuineIntel 686-class) 722 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real mem = 536375296 (523804K) avail mem = 482398208 (471092K) using 4278 buffers containing 26923008 bytes (26292K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(a3) BIOS, date 06/28/00, BIOS32 rev. 0 @ 0xfb380 apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown apm0: flags 70102 dobusy 1 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xf/0xb808 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf00/144 (7 entries) pcibios0: PCI Exclusive IRQs: 10 11 12 pcibios0: PCI Interrupt Router at 000:07:0 (Intel 82371SB ISA rev 0x00) pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc/0x8000 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82443BX
Re: Odd df reporting (On Apr 3 snapshot, data copied via 3.8snapshot)
Yeah! that is the thing I didn't do! Run fsck against the affected partition! Anyways, as per your questions: I copied the with cp, eg: # cd /mnt/wd1a # cp -R Anime /mnt/wd2d Here are the raw df output from the current snapshot kernel [brought to you by the wonders of OpenSSH]: # df Filesystem 512-blocks Used Avail Capacity Mounted on /dev/wd0a 18572172 1062820 16580744 6%/ /dev/wd0d123841300 4215514788 197101744 14535%/mnt/wd0d /dev/wd0e123841300 13434788 10421444811%/mnt/wd0e /dev/wd0f212356232 66929816 13480860833%/mnt/wd0f # I had torrent'd the Olive OpenBSD live cd awhile back that was a December? -stable 3.8 (I think), could I use that to run fsck against the affected partition? That would be easier to do than to hookup the 40gig that contained the Dec snapshot (I don't have a copy of either 3.8/3.9 -release available, but I will make one and install it if you want me to). Cheers, thanks for the reply!! On 06/04/06, Otto Moerbeek [EMAIL PROTECTED] wrote: On Wed, 5 Apr 2006, Whyzzi wrote: I've had a strange occurance I'd like to report, in using df -h, but the circumstances that brought about this condition are somewhat unusual, so I really don't know if it is anything to be concerned about. This might also have already been fixed, as I do not follow tech/src Background: I have setup a home based samba media file server, originally running 3.8; a snapshot from Dec. The files on this server was split between 2 drives, a decrepid 30gig IBM/Hitachi, and a Maxtor 40gig. Pulled the plug on the two drives, and connected the a Seagate 250Gig IDE HD. (primary master IDE). Installed the April 3rd snapshot on it via dvdrw. Gave root 9Gig at the front of the drive, swap 1gig, created 2 60gig partitions, and 100gig, all with pre-setup mount points (df, disklabel, fstab, dmesg included @ end). Disconnected dvdrw, connected the 250Gig to the secondary IDE master, and booted into the older 3.8 snapshot. Mounted one of the partitions I created in 3.9, and proceded to copy the files over (yeah, 50+gigs over UDMA33 without softdep can take quite some time to copy on a P3 700). When that was finally done, and since I had the root of 3.9 accessible, I modified 3.9's fstab to include softdep, modified pf, modified rc/rc.conf, plus startup config stuff. Then I turned off the PC removed the 30 40gig drives, mounted the 250gig to the case - and reconnected it to the primary ide interface on the mainboard, and reconnected the dvdrw drive. Originally, when I had booted up, df was reporting (no snapshot taken) no additional space used by the partition (ie freshly formated, even though I had copied stuff there in 3.8). I've since moved the directories I wanted to move, and now df is reporting wayy over the size limit. So before I move the last of the information around reformat the partition to return accurate results, I thought I'd share with the list what I am seeing: ## df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/wd0a 8.9G519M7.9G 6%/ /dev/wd0d 59.1G8.0T 94.0G 14535%/mnt/wd0d /dev/wd0e 59.1G6.4G 49.7G11%/mnt/wd0e /dev/wd0f 101G 31.7G 64.4G33%/mnt/wd0f How did you copy the files? There have been some changes wrt filesystems. Too see if they have anything to do with it, please try the following: - run a 3.9 (or 3.8 if you do not have that) release kernel, and check the numbers. - umount the filesystem and run fsck -f on /dev/wd0d - remount and check nunbers - go back to the snap kernel and repeat. oh and report the output of df without -h, I like to see the raw numbers. -Otto ## disklabel wd0 # Inside MBR partition 3: type A6 start 63 size 488392002 # /dev/rwd0c: type: ESDI disk: ESDI/IDE disk label: ST3250823A flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 16383 total sectors: 488397168 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 16 partitions: # sizeoffset fstype [fsize bsize cpg] a: 1887473763 4.2BSD 2048 16384 328 # Cyl 0*- 18724 b: 2097648 18874800swap # Cyl 18725 - 20805 c: 488397168 0 unused 0 0 # Cyl 0 -484520 d: 125828640 20972448 4.2BSD 2048 16384 328 # Cyl 20806 -145635 e: 125828640 146801088 4.2BSD 2048 16384 328 # Cyl 145636 -270465 f: 215762337 272629728 4.2BSD 2048 16384 328 # Cyl 270466 -484515* cat /etc/fstab /dev/wd0a / ffs rw 1 1 /dev/wd0d /mnt/wd0d ffs rw,nodev,nosuid,softdep 1 2 /dev/wd0e /mnt/wd0e ffs
