Re: file disappeared?
And next time you have a big file you want to get rid of, cp /dev/null foo, then rm foo. dc -- David Coder NOC Op Erols Internet Service/RCN On Tue, 27 Apr 1999, Mark Newton wrote: :Date: Tue, 27 Apr 1999 09:37:42 +0930 (CST) :From: Mark Newton new...@internode.com.au :To: Alex a...@ukc.ac.uk :Cc: doo...@anet-stl.com, dwh...@resnet.uoregon.edu, :freebsd-current@FreeBSD.ORG :Subject: Re: file disappeared? : :Alex wrote: : : The question is how badly did I screw things up by running fsck? : (I think with -p it doesn't actually salvage anything, just checks the : disk). : Worth a reboot? : :Definitely: -p *does* salvage things. Boot to single user and run :fsck manually to make sure everything's ok. : :- mark : : :Mark Newton Email: new...@internode.com.au (W) :Network Engineer Email: new...@atdot.dotat.org (H) :Internode Systems Pty Ltd Desk: +61-8-82232999 :Network Man - Anagram of Mark Newton Mobile: +61-416-202-223 : : :To Unsubscribe: send mail to majord...@freebsd.org :with unsubscribe freebsd-current in the body of the message : To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
file disappeared?
The subject says it all: I removed a file, but according to df, it's still there! pcayk:~/tmp$ df -k . Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/wd0s1f7621844 69756693642899%/usr pcayk:~/tmp$ ls -l -rw-r--r-- 1 ayk1 users 716247040 Apr 22 1999 bigcdimage.iso pcayk:~/tmp$ rm bigcdimage.iso pcayk:~/tmp$ df -k . Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/wd0s1f7621844 69756693642899%/usr How on earth did that happen?!!! So I decided to run fsck, with -p at first: pcayk:/usr/home/ayk1# fsck -p -f /dev/wd0s1f /dev/rwd0s1f: UNREF FILE I=053 OWNER=ayk1 MODE=100644 /dev/rwd0s1f: SIZE=716247040 MTIME=Apr 22 20:36 1999 (CLEARED) /dev/rwd0s1f: SUMMARY INFORMATION BAD (SALVAGED) /dev/rwd0s1f: BLK(S) MISSING IN BIT MAPS (SALVAGED) /dev/rwd0s1f: FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED) /dev/rwd0s1f: 176217 files, 6275813 used, 1346031 free (39575 frags, 163307 blocks, 0.5% fragmentation) OK - the file's there - time to salvage it. pcayk:/usr/home/ayk1# fsck -f /dev/wd0s1f ** /dev/rwd0s1f ** Last Mounted on /usr ** 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? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y 176217 files, 6275839 used, 1346005 free (39581 frags, 163303 blocks, 0.5% fragmentation) * FILE SYSTEM MARKED CLEAN * * FILE SYSTEM WAS MODIFIED * pcayk:/usr/home/ayk1# df -k Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/wd0s1a 63503327992562456%/ /dev/wd0s1f 7621844 69756643643399%/usr /dev/wd0s1e 63503112114721219%/var /dev/wd2s1e 8002964 734610716620 100%/usr/local/mp3-archive procfs 440 100%/proc Arrgghhh - now I've done it! Any suggestions on how to deal with this? Thanks, Alex pcayk:~/tmp$ uname -a FreeBSD pcayk.ukc.ac.uk 3.1-STABLE FreeBSD 3.1-STABLE #0: Sun Apr 4 15:58:45 BST 1999 a...@pcayk.ukc.ac.uk:/usr/src/sys/compile/SHAKA i386 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: file disappeared?
Dean Lombardo didn't write: The subject says it all: I removed a file, but according to df, it's still there! (snipped) Thanks, Alex Sorry about the name mixup - I accidentally left Netscape open on a friend's box...Anyway, email a...@ukc.ac.uk, not me! Dean To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: file disappeared?
On Mon, 26 Apr 1999, Dean Lombardo wrote: The subject says it all: I removed a file, but according to df, it's still there! pcayk:~/tmp$ df -k . Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/wd0s1f7621844 69756693642899%/usr pcayk:~/tmp$ ls -l -rw-r--r-- 1 ayk1 users 716247040 Apr 22 1999 bigcdimage.iso pcayk:~/tmp$ rm bigcdimage.iso pcayk:~/tmp$ df -k . Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/wd0s1f7621844 69756693642899%/usr How on earth did that happen?!!! Are you running soft updates? It takes ~30s for changes to take effect if you are. I noticed this myself last week. So I decided to run fsck, with -p at first: pcayk:/usr/home/ayk1# fsck -p -f /dev/wd0s1f /dev/rwd0s1f: UNREF FILE I=053 OWNER=ayk1 MODE=100644 /dev/rwd0s1f: SIZE=716247040 MTIME=Apr 22 20:36 1999 (CLEARED) /dev/rwd0s1f: SUMMARY INFORMATION BAD (SALVAGED) /dev/rwd0s1f: BLK(S) MISSING IN BIT MAPS (SALVAGED) /dev/rwd0s1f: FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED) /dev/rwd0s1f: 176217 files, 6275813 used, 1346031 free (39575 frags, 163307 blocks, 0.5% fragmentation) I assume this was in single user mode, otherwise you made a gigantic mess. :-) Doug White Internet: dwh...@resnet.uoregon.edu| FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite| www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: file disappeared?
Thank you for a quick response. pcayk:~/tmp$ df -k . Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/wd0s1f7621844 69756693642899%/usr pcayk:~/tmp$ ls -l -rw-r--r-- 1 ayk1 users 716247040 Apr 22 1999 bigcdimage.iso pcayk:~/tmp$ rm bigcdimage.iso pcayk:~/tmp$ df -k . Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/wd0s1f7621844 69756693642899%/usr How on earth did that happen?!!! Are you running soft updates? It takes ~30s for changes to take effect if you are. I noticed this myself last week. I believe not - doesn't that involve adding a SOFTUPDATES option to the kernel? I don't have that in my kernel; therefore, disc access should be synchronous by default, right? And it had definitely been longer than 30s before I decided to run fsck (or before the first run completed). What does it all mean? That I have a file occupying 700+ Mb on my hard drive that I can't get rid of? :-( By the way, rm returned almost instantaneously - normally it takes a few seconds to remove such a huge file (that was the reason I even noticed the problem in the first place.) If this is a bug, I would be glad to help, but this kind of error is hard to reproduce... Perhaps someone with an in-depth knowledge of ufs can tell me what really happened (and what exactly did fsck do to my drive, just to make things worse.) So I decided to run fsck, with -p at first: pcayk:/usr/home/ayk1# fsck -p -f /dev/wd0s1f /dev/rwd0s1f: UNREF FILE I=053 OWNER=ayk1 MODE=100644 /dev/rwd0s1f: SIZE=716247040 MTIME=Apr 22 20:36 1999 (CLEARED) /dev/rwd0s1f: SUMMARY INFORMATION BAD (SALVAGED) /dev/rwd0s1f: BLK(S) MISSING IN BIT MAPS (SALVAGED) /dev/rwd0s1f: FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED) /dev/rwd0s1f: 176217 files, 6275813 used, 1346031 free (39575 frags, 163307 blocks, 0.5% fragmentation) I assume this was in single user mode, otherwise you made a gigantic mess. :-) I did, didn't I? Alex --- A mathematician is a machine for converting coffee into theorems. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: file disappeared?
Doug White wrote: On Mon, 26 Apr 1999, Dean Lombardo wrote: So I decided to run fsck, with -p at first: pcayk:/usr/home/ayk1# fsck -p -f /dev/wd0s1f /dev/rwd0s1f: UNREF FILE I=053 OWNER=ayk1 MODE=100644 /dev/rwd0s1f: SIZE=716247040 MTIME=Apr 22 20:36 1999 (CLEARED) /dev/rwd0s1f: SUMMARY INFORMATION BAD (SALVAGED) /dev/rwd0s1f: BLK(S) MISSING IN BIT MAPS (SALVAGED) /dev/rwd0s1f: FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED) /dev/rwd0s1f: 176217 files, 6275813 used, 1346031 free (39575 frags, 163307 blocks, 0.5% fragmentation) I assume this was in single user mode, otherwise you made a gigantic mess. :-) Doesn't the file system just need to be unmounted? Qualifier: I'm not a file system hacker. Can VFS_STATFS return a value that indicates whether a file system is mounted? If so, it would seem logical to have fsck check the status. status = VFS_STATFS(mp, sbp, p); if (status MOUNTED) perror(file system mounted); -- Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: file disappeared?
A file's storage isn't freed until its last reference is removed. An open file descriptor is a reference. Do you perhaps have a hung CD burner process or something similar running? If there is something holding that file open, a reboot would almost certainly clear the space. Jason Young ANET Chief Network Engineer -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org]on Behalf Of Alex Sent: Monday, April 26, 1999 1:44 PM To: Doug White Cc: freebsd-current@FreeBSD.ORG Subject: Re: file disappeared? Thank you for a quick response. pcayk:~/tmp$ df -k . Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/wd0s1f7621844 69756693642899%/usr pcayk:~/tmp$ ls -l -rw-r--r-- 1 ayk1 users 716247040 Apr 22 1999 bigcdimage.iso pcayk:~/tmp$ rm bigcdimage.iso pcayk:~/tmp$ df -k . Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/wd0s1f7621844 69756693642899%/usr How on earth did that happen?!!! Are you running soft updates? It takes ~30s for changes to take effect if you are. I noticed this myself last week. I believe not - doesn't that involve adding a SOFTUPDATES option to the kernel? I don't have that in my kernel; therefore, disc access should be synchronous by default, right? And it had definitely been longer than 30s before I decided to run fsck (or before the first run completed). What does it all mean? That I have a file occupying 700+ Mb on my hard drive that I can't get rid of? :-( By the way, rm returned almost instantaneously - normally it takes a few seconds to remove such a huge file (that was the reason I even noticed the problem in the first place.) If this is a bug, I would be glad to help, but this kind of error is hard to reproduce... Perhaps someone with an in-depth knowledge of ufs can tell me what really happened (and what exactly did fsck do to my drive, just to make things worse.) So I decided to run fsck, with -p at first: pcayk:/usr/home/ayk1# fsck -p -f /dev/wd0s1f /dev/rwd0s1f: UNREF FILE I=053 OWNER=ayk1 MODE=100644 /dev/rwd0s1f: SIZE=716247040 MTIME=Apr 22 20:36 1999 (CLEARED) /dev/rwd0s1f: SUMMARY INFORMATION BAD (SALVAGED) /dev/rwd0s1f: BLK(S) MISSING IN BIT MAPS (SALVAGED) /dev/rwd0s1f: FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED) /dev/rwd0s1f: 176217 files, 6275813 used, 1346031 free (39575 frags, 163307 blocks, 0.5% fragmentation) I assume this was in single user mode, otherwise you made a gigantic mess. :-) I did, didn't I? Alex --- A mathematician is a machine for converting coffee into theorems. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: file disappeared?
In reply: Can VFS_STATFS return a value that indicates whether a file system is mounted? If so, it would seem logical to have fsck check the status. status = VFS_STATFS(mp, sbp, p); if (status MOUNTED) perror(file system mounted); I am saying this without having looked at the code first, but I believe that it is already impossible to umount a filesystem with any OPEN files on it: filesystem in use. Assuming that all of the buffers are flushed upon close, the only thing you really should get is a clean flag problem, as would happen in a crash on a filesystem with no open files. It looks more like he crashed to me, but then something could be munged up in the code. is softupdates on? jim -- All opinions expressed are mine, if you| I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered! - #1, The Prisoner -- Inet: jbry...@tfs.netAX.25: kc5...@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant -- HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: file disappeared?
Dean Lombardo wrote: Dean Lombardo didn't write: The subject says it all: I removed a file, but according to df, it's still there! Some running process still has the file open. As soon as that process exits, the space will be freed. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: file disappeared?
A file's storage isn't freed until its last reference is removed. An open file descriptor is a reference. Do you perhaps have a hung CD burner process or something similar running? Nothing like that - I used a CD burner on another machine, and then ftp'ed the image to my home dir in case I needed more copies. After a few days, I decided that I didn't need it after all, and deleted it... or did I? The question is how badly did I screw things up by running fsck? It still reports pcayk:/etc# fsck -p -f /dev/wd0s1f /dev/rwd0s1f: FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED) /dev/rwd0s1f: SUMMARY INFORMATION BAD (SALVAGED) /dev/rwd0s1f: BLK(S) MISSING IN BIT MAPS (SALVAGED) /dev/rwd0s1f: 176225 files, 6278980 used, 1342864 free (39576 frags, 162911 blocks, 0.5% fragmentation) (I think with -p it doesn't actually salvage anything, just checks the disk). Worth a reboot? Alex --- A mathematician is a machine for converting coffee into theorems. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: file disappeared?
On Mon, 26 Apr 1999, Jim Bryant wrote: In reply: Can VFS_STATFS return a value that indicates whether a file system is mounted? If so, it would seem logical to have fsck check the status. status = VFS_STATFS(mp, sbp, p); if (status MOUNTED) perror(file system mounted); I am saying this without having looked at the code first, but I believe that it is already impossible to umount a filesystem with any OPEN files on it: filesystem in use. umount -f will force a dismount and make all open references go to deadfs afaik. -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: file disappeared?
Jim Bryant wrote: In reply: Can VFS_STATFS return a value that indicates whether a file system is mounted? If so, it would seem logical to have fsck check the status. status = VFS_STATFS(mp, sbp, p); if (status MOUNTED) perror(file system mounted); I am saying this without having looked at the code first, but I believe that it is already impossible to umount a filesystem with any OPEN files on it: filesystem in use. Assuming that all of the buffers are flushed upon close, the only thing you really should get is a clean flag problem, as would happen in a crash on a filesystem with no open files. I wasn't clear in my response. Running fsck -p on a mounted file system can supposedly lead to Bad Things. It seems that fsck should determine if the file systm is mounted before it can to some damage. -- Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: file disappeared?
The subject says it all: I removed a file, but according to df, it's still there! Some running process still has the file open. As soon as that process exits, the space will be freed. Of course... stupid me! I used vnconfig to mount the image and then unmounted it, but forgot to do a vnconfig -u... Of course, it's a bit too late now - just got a kernel panic trying to do so (not entirely unexpected - anyone want a core dump... :-) vnconfig was a one-off thing and not a running process, therefore difficult to detect. Many thanks to everyone who responded, and I do apologise for wasting your time. Alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: file disappeared?
:Nothing like that - I used a CD burner on another machine, and then ftp'ed :the image to my home dir in case I needed more copies. After a few days, :I decided that I didn't need it after all, and deleted it... or did I? : :The question is how badly did I screw things up by running fsck? : :It still reports : :pcayk:/etc# fsck -p -f /dev/wd0s1f :/dev/rwd0s1f: FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED) :/dev/rwd0s1f: SUMMARY INFORMATION BAD (SALVAGED) :/dev/rwd0s1f: BLK(S) MISSING IN BIT MAPS (SALVAGED) :/dev/rwd0s1f: 176225 files, 6278980 used, 1342864 free (39576 frags, :162911 blocks, 0.5% fragmentation) : :(I think with -p it doesn't actually salvage anything, just checks the :disk). : :Worth a reboot? : :Alex Good god. Alex. NEVER RUN FSCK OUTSIDE OF SINGLE-USER MODE. Also, never 'guess' what an option is supposed to do. Read the man page. In this case, you guessed wrong. -p does salvage things. Reboot, get into the boot prompt, type 'boot -s' ( if a newer boot prompt ) or simply '-s' if an older boot prompt. When you get into SINGLE user mode, type 'fsck'. Do not specify any other options. The fsck run in normal boot will not properly clean up the mess, because the filesystem will probably be marked valid when it isn't. Then reboot again. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: file disappeared?
In reply: On Mon, 26 Apr 1999, Jim Bryant wrote: In reply: Can VFS_STATFS return a value that indicates whether a file system is mounted? If so, it would seem logical to have fsck check the status. status = VFS_STATFS(mp, sbp, p); if (status MOUNTED) perror(file system mounted); I am saying this without having looked at the code first, but I believe that it is already impossible to umount a filesystem with any OPEN files on it: filesystem in use. umount -f will force a dismount and make all open references go to deadfs afaik. -Alfred I stand corrected. I must of misinterpreted the -f to mean -f[orget-this-option!], in a moment of self-preservation. As I recall -f is a last resort. jim -- All opinions expressed are mine, if you| I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered! - #1, The Prisoner -- Inet: jbry...@tfs.netAX.25: kc5...@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant -- HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: file disappeared?
Fscking a live system is a Bad Idea(tm) and should be avoided. Reboot into single-user and fsck it manually (while unmounted). Jason Young ANET Chief Network Engineer -Original Message- From: Alex [mailto:a...@ukc.ac.uk] Sent: Monday, April 26, 1999 2:06 PM To: Jason Young Cc: Doug White; freebsd-current@FreeBSD.ORG Subject: RE: file disappeared? A file's storage isn't freed until its last reference is removed. An open file descriptor is a reference. Do you perhaps have a hung CD burner process or something similar running? Nothing like that - I used a CD burner on another machine, and then ftp'ed the image to my home dir in case I needed more copies. After a few days, I decided that I didn't need it after all, and deleted it... or did I? The question is how badly did I screw things up by running fsck? It still reports pcayk:/etc# fsck -p -f /dev/wd0s1f /dev/rwd0s1f: FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED) /dev/rwd0s1f: SUMMARY INFORMATION BAD (SALVAGED) /dev/rwd0s1f: BLK(S) MISSING IN BIT MAPS (SALVAGED) /dev/rwd0s1f: 176225 files, 6278980 used, 1342864 free (39576 frags, 162911 blocks, 0.5% fragmentation) (I think with -p it doesn't actually salvage anything, just checks the disk). Worth a reboot? Alex --- A mathematician is a machine for converting coffee into theorems. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: file disappeared?
On Mon, 26 Apr 1999, Alex wrote: pcayk:~/tmp$ df -k . Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/wd0s1f7621844 69756693642899%/usr pcayk:~/tmp$ ls -l -rw-r--r-- 1 ayk1 users 716247040 Apr 22 1999 bigcdimage.iso pcayk:~/tmp$ rm bigcdimage.iso pcayk:~/tmp$ df -k . Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/wd0s1f7621844 69756693642899%/usr How on earth did that happen?!!! Are you running soft updates? It takes ~30s for changes to take effect if you are. I noticed this myself last week. I believe not - doesn't that involve adding a SOFTUPDATES option to the kernel? I don't have that in my kernel; therefore, disc access should be synchronous by default, right? And it had definitely been longer than 30s before I decided to run fsck (or before the first run completed). If you're running default disk access then I'm guessing some program still has the file open. Perhaps 'cdrecord' hung? I assume this was in single user mode, otherwise you made a gigantic mess. :-) I did, didn't I? For the future, running fsck in multiuser mode is a no-no. Doug White Internet: dwh...@resnet.uoregon.edu| FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite| www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: file disappeared?
Doug White once wrote: I assume this was in single user mode, otherwise you made a gigantic mess. :-) I did, didn't I? For the future, running fsck in multiuser mode is a no-no. Not in multiuser mode but on a mounted filesystem, is it? -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: file disappeared?
According to Dean Lombardo: How on earth did that happen?!!! Are you using softupdates ? If yes, there is a 30s window where the space is still taken and not given back to the system. So I decided to run fsck, with -p at first: Never run fsck on a live filesystem, you could screw up yourself big time. Any suggestions on how to deal with this? Either do a lot of sync or just wait 30s. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #2: Fri Apr 16 22:37:03 CEST 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: file disappeared?
On Mon, 26 Apr 1999, Mikhail Teterin wrote: Doug White once wrote: I assume this was in single user mode, otherwise you made a gigantic mess. :-) I did, didn't I? For the future, running fsck in multiuser mode is a no-no. Not in multiuser mode but on a mounted filesystem, is it? Actually, I believe you're correct. I apologize for the goof. Doug White Internet: dwh...@resnet.uoregon.edu| FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite| www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: file disappeared?
Alex wrote: pcayk:~/tmp$ rm bigcdimage.iso pcayk:~/tmp$ df -k . Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/wd0s1f7621844 69756693642899%/usr How on earth did that happen?!!! Are you running soft updates? It takes ~30s for changes to take effect if you are. I noticed this myself last week. I believe not - doesn't that involve adding a SOFTUPDATES option to the kernel? I don't have that in my kernel; therefore, disc access should be synchronous by default, right? And it had definitely been longer than 30s before I decided to run fsck (or before the first run completed). Ok, something has the file open then - storage is not freed until the last reference to the file disappears. This is so that you can rm a file on a multitasking system without making processes that might be using the file at the time fall over and die (for a similar effect, try rm /var/log/messages -- You'll note that storage for the file isn't freed until you kill syslogd; in fact, if you generage log messages the file will grow and consume more space even though it doesn't have a directory entry. An application might have the file open; Alternatively, since it's a disk image which I presume you've been testing, you could have it attached to a vn device; if that's the case, something like vnconfig -u /dev/vn0 will detach it, close the last reference to the file, and free the associated storage. Finally, it's possible that there was a hard link to the file. Given that fsck bitched about it being an unref'ed file that's probably unlikely, but the fact stil remains that hardlinks are a legitimate reason for storage to remain allocated after you've deleted something: Once again, the file isn't really deleted until the last reference to it disappears. Perhaps someone with an in-depth knowledge of ufs can tell me what really happened (and what exactly did fsck do to my drive, just to make things worse.) No need for an in-depth knowledge of UFS; this is standard UNIX behaviour, regardless of the underlying filesystem. - mark Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: file disappeared?
Alex wrote: The question is how badly did I screw things up by running fsck? (I think with -p it doesn't actually salvage anything, just checks the disk). Worth a reboot? Definitely: -p *does* salvage things. Boot to single user and run fsck manually to make sure everything's ok. - mark Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
