Date: Tue, 24 Jun 2008 05:13:03 +0000 From: Helge Rohde <heroh@gmx.de> To: freebsd-questions@freebsd.org Subject: Re: shellscript conditional to check for external disk Message-ID: <200806240513.03666.heroh@gmx.de> In-Reply-To: <20080623182459.GA15276@slackbox.xs4all.nl> References: <200806212144.09925.heroh@gmx.de> <200806231725.58862.heroh@gmx.de> <20080623182459.GA15276@slackbox.xs4all.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 23 June 2008 18:24:59 Roland Smith wrote: > On Mon, Jun 23, 2008 at 05:25:58PM +0000, Helge Rohde wrote: > > On Saturday 21 June 2008 22:47:31 Roland Smith wrote: > > > On Sat, Jun 21, 2008 at 09:44:09PM +0000, Helge Rohde wrote: > > > > Is there a canonical way to achieve what i want? I played with the > > > > idea of simply checking for /dev/da0s1d's existance, but that won't > > > > disappear on disconnect, so that would leave the is a possibility > > > > that although > > Such devices should disappear on disconnect. That's what i thought, but since i wasnt entirely sure i let the otherwise perfectly working behavior convince me otherwise. Sorry for any confusion caused. It seems that with the given Hardware combination fwohci runs into a bunch of errors and only creates the device nodes at the first time the drive is connected, but fails to destroy them upon disconnection. Reconnecting, mounting and writing to and from the device node produced no errors. If i connect the drive via usb cable instead of the fw one, all goes as expected and umass creates and destroys the device nodes. I will investigate and start a new thread on it later, for now my workaround is a strip of Gaffa Tape over the Firewire port and the instruction to only use USB ;) > > > > da0 is in /dev, it might not be connected. > > > > > > Use glabel(8) to give the device an unique label. There is no telling > > > which device /dev/da0s1d is pointing to! After labeling you can check > > > for /dev/<fstype>/<yourlabel>, which should be unique. > > Let me rephrase that. You should actually use the file system's utility > to set a label. This works for UFS (newfs, tunefs), msdosfs (newfs_msdos), > ISO9660 (mkisofs) and ntfs. > > > > Make sure to unmount the drive at the end of the backup script, or > > > you'll get a kernel panic when staff pulls the plug on a mounted > > > device. > > > > > > Roland > > > > Okay, it obviosly makes sense to use glabel instead of the device node. > > Will the glabel appear/disappear depending on whether the drive is > > connected? > > Yes, just like regular device nodes. I just didnt suspect just how irregular my device nodes are ;) > > Is it possible to have more then one physical drive with the same > > glabel(As i plan to utilize two identical Firewire disks) ? > > You can label both drives the same. I don't know what will happen it you > try to connect them both at the same time. I guess that the creation of > the second label will fail. > > > Either way, i still need a way to check whether a drive is attached or > > not. > > Simple. Check for the device node. > > > Mounting( and unmounting!) will be done from the periodic backup > > scripts. > > > > I am not sure how devd could help me with that, besides maybe > > write/delete a zero-byte file somewhere and have the periodic script > > check for its existence. > > It can't completely. It should be able to detect your labeled device and > mount it somewhere. But you _have_ to unmount _before_ the device node > disappears, lest you get the aforementioned panic. Thats precisely why i didnt want to let devd do the mounting: doing it just-in-time minimises the window of opportunity for vicious plug-pullers. > It's easier to have the backup script test if the labeled device node > exists. > > Do not forget to print a message (after the script has unmounted the > drive) for the operators that the backup is finished and that the device > may be disconnected. The Machine will run headless - I thought about sending a mail but i probably won't bother as by the time the backup and copy takes longer than a night, I should have received angry emails and snmp traps about filesystems way beyond their official capacity anyway ;) regards, Helge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200806240513.03666.heroh>