Panic on umount -f
Hello, freebsd-questions. After the following actions: 1. Insert USB Flash 2. mount_msdosfs /dev/da0s1 /mnt 3. Remove USB Flash 4. umount -f /mnt I have kernel panic every time. Is this a known issue? My system is FreeBSD 7.0-RC1 from 1.01.2008. -- Best regards, Michael mailto:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic on umount -f
Michael Lednev wrote: Hello, freebsd-questions. After the following actions: 1. Insert USB Flash 2. mount_msdosfs /dev/da0s1 /mnt 3. Remove USB Flash 4. umount -f /mnt I have kernel panic every time. Is this a known issue? My system is FreeBSD 7.0-RC1 from 1.01.2008. Yes, long-standing issue with unexpected mounted device removal. Don't do that :) Kris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic on umount -f
Hello, Kris. On 2 ?? 2008 ?., 14:07:36 you wrote: KK Yes, long-standing issue with unexpected mounted device removal. Don't KK do that :) Thanks, already found this PR, it's already 5 yo, wow :) -- Best regards, Michael mailto:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic on umount -f
Michael Lednev wrote: Hello, Kris. On 2 ?? 2008 ?., 14:07:36 you wrote: KK Yes, long-standing issue with unexpected mounted device removal. Don't KK do that :) Thanks, already found this PR, it's already 5 yo, wow :) There have been some recent partial workarounds committed in current, but this issue is quite difficult to fix completely. Kris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umount -f Complete system crash...
On 28/07/07, Modulok [EMAIL PROTECTED] wrote: BACKGROUND Someone brought me a camera they were having trouble with: winXP refused to mount the file system. I tried it on FreeBSD 6.1-RELEASE, mount_msdosfs /dev/da0s1 /mnt, no problems. I recovered all of their photos. I attempted to umount /mnt and encountered an error, something along the lines of cannot contact device, (I don't remember exactly. No, I wasn't in the directory I was attempting to umount.). No other process was communicating with the device, according to the camera it was 'idle'. I issued a umount -f /mnt command. The entire system locked up for a few seconds (maybe 4) and then CRASH! I found myself looking at my BIOS output as the system reboots. QUESTIONS 1. Obviously, why did FreeBSD crash? (More specifically what could cause a crash in this situation?) 2. How do I find out, why it crashed? 3. Did I do something terribly unorthodox to invoke this crash, given the situation? If so, what could be done different? The camera powered itself down after being idle for a bit, perhaps? There have been some recent discussions, about physical disconnections of mounted devices causing panics, on this list over the last several weeks. -- -- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
umount -f Complete system crash...
BACKGROUND Someone brought me a camera they were having trouble with: winXP refused to mount the file system. I tried it on FreeBSD 6.1-RELEASE, mount_msdosfs /dev/da0s1 /mnt, no problems. I recovered all of their photos. I attempted to umount /mnt and encountered an error, something along the lines of cannot contact device, (I don't remember exactly. No, I wasn't in the directory I was attempting to umount.). No other process was communicating with the device, according to the camera it was 'idle'. I issued a umount -f /mnt command. The entire system locked up for a few seconds (maybe 4) and then CRASH! I found myself looking at my BIOS output as the system reboots. QUESTIONS 1. Obviously, why did FreeBSD crash? (More specifically what could cause a crash in this situation?) 2. How do I find out, why it crashed? 3. Did I do something terribly unorthodox to invoke this crash, given the situation? If so, what could be done different? Any pointers would be appreciated. -Modulok- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
umount -f
Couple questions for anyone on the list who has a moment (and the answer to any of these): Objective: I need to kick people off of a storage drive (we'll say /dev/ad4), without corrupting the file system and without bringing the entire system down. I need to safely umount the file systems, even if my users have processes which have files open. 1. If I use umount -f /dev/ad4s1a to forcefully umount a file system, does this jeopardize the integrity of said file system? Like...will it jerk the run out from under a process in the middle of a disk write, thus leaving a half written file, or will it wait until the write is complete? (I guess this would largely depend on the disk controller?) 2. How do I get a list of processes that are accessing a specific file system, e.g. /dev/ad4s1a? 3. Is there any safe way to unconditionally umount a file system, even if a run-away process is writing to it (as bad of an idea as this is)? Thanks. -Modulok- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umount -f
Modulok [EMAIL PROTECTED] wrote: Couple questions for anyone on the list who has a moment (and the answer to any of these): Objective: I need to kick people off of a storage drive (we'll say /dev/ad4), without corrupting the file system and without bringing the entire system down. I need to safely umount the file systems, even if my users have processes which have files open. 1. If I use umount -f /dev/ad4s1a to forcefully umount a file system, does this jeopardize the integrity of said file system? Like...will it jerk the run out from under a process in the middle of a disk write, thus leaving a half written file, or will it wait until the write is complete? (I guess this would largely depend on the disk controller?) I don't believe there are any guarantees if your -f it. The filesystem will probably be OK, but I would expect files to get corrupt. 2. How do I get a list of processes that are accessing a specific file system, e.g. /dev/ad4s1a? fstat(1) is your friend. 3. Is there any safe way to unconditionally umount a file system, even if a run-away process is writing to it (as bad of an idea as this is)? I would write a script that pulls fstat data, then kills any processes with files open, then attempts to unmount the filesystem. If that fails, go through the fstat data again and kill -9 the processes this time. If all that fails, you can finally choose to umount -f. You could also try some looping constructs, kill/umount four or five times before switching to kill -9/umount, etc. It all depends on how desperate you are to get the filesystem unmounted, how long you're willing to wait, how much data you're willing to lose, etc. -- Bill Moran http://www.potentialtech.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umount -f
On Mon, Jun 11, 2007 at 08:17:14PM -0400, Bill Moran wrote: Modulok [EMAIL PROTECTED] wrote: Couple questions for anyone on the list who has a moment (and the answer to any of these): Objective: I need to kick people off of a storage drive (we'll say /dev/ad4), without corrupting the file system and without bringing the entire system down. I need to safely umount the file systems, even if my users have processes which have files open. 1. If I use umount -f /dev/ad4s1a to forcefully umount a file system, does this jeopardize the integrity of said file system? Like...will it jerk the run out from under a process in the middle of a disk write, thus leaving a half written file, or will it wait until the write is complete? (I guess this would largely depend on the disk controller?) I don't believe there are any guarantees if your -f it. The filesystem will probably be OK, but I would expect files to get corrupt. Shouldn't happen, if it does it's a bug. Kris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umount -f
On 11/06/07, Modulok [EMAIL PROTECTED] wrote: 3. Is there any safe way to unconditionally umount a file system, even if a run-away process is writing to it (as bad of an idea as this is)? UFS is refreshingly robust (at least in my experience) in this regard, in that you may end up with a truncated (or slightly mauled) file but never a corrupt filesystem. Even kicking the power cord out only results in minor, repairable corruption something like 30% of the time. Again, in terms of personal experience I would suggest that umount -f is shrug-inducingly safe at 3 or 4 nines of the time. -- -- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umount -f
1. If I use umount -f /dev/ad4s1a to forcefully umount a file system, does this jeopardize the integrity of said file system? Like...will it jerk the run out from under a process in the middle of a disk write, thus leaving a half written file, or will it wait until the write is complete? (I guess this would largely depend on the disk controller?) I don't believe there are any guarantees if your -f it. The filesystem will probably be OK, but I would expect files to get corrupt. Shouldn't happen, if it does it's a bug. umount -f should not corrupt the filesystem, IOW fsck of an FS immediately after umount -f should not report anything more serious than some homeless files (if the last link had been removed, but the inode had not been released because some process still had it open). However data corruption seems likely if it yanks the rug out from under a process that has, say, written part of a transaction to a database file. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
NFS client hang after umount -f
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was transferring a huge file (700 MB) to an nfs mounted disc and I umount -f the nfs mounted directory. After this I lost control of that pc (I was remotely administering it). The machine responds to pings and forwards packets as well, but if I try to telnet or ssh to it, I connect to that box but no login prompt appear. I dont have physical access to that box and so I wait for 1 week for someone to go there and reboot it, but I am very curious why this situation happened. Is it normal to happen when u use unmount -f on nfs mounted drives??? I am running 4.7-p2 and I dont have any noticable problems. The gateway machine is a diskless machine with local mounted discs for storing files only. Thanks in advance!!! - --- We are being monitored..but there is a solution... Use PGP for signing and encrypting emails Download my public key at http://www.us.pgp.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+FXpoGe/V3CxAyHoRAt1OAJ9q9eTCKN6Xfj7sX+uu8S7D50ulPACeJRW3 BPjpAAhV0RcrgZ/VqZ6l3UI= =u2dQ -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
