<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.6000.16640" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>Pull out the tapes? You were using that snapshot feature on your SAN, right? When someone runs mkfs over a block device like that, the results are not likely to be good, and rarely are recoverable without some sort of outside restore. I've found snapshots wonderful for situations like this :-).</DIV>
<DIV> </DIV>
<DIV>The larger issue, I've found (from some bad experiences, though not quite with such important data), is that your SAN should only allow certain hosts to connect to those volumes. Most SANs feature access control of some sort, and setting things up so that everyone or even an entire subnet can access a volume is pretty dangerous and will result in something like this. Doesn't help you much now, but in the future make sure to implement (finer) access control on your volumes.</DIV>
<DIV> </DIV>
<DIV>-Nick<BR><BR>>>> On 2008/04/25 at 02:33, Christian Lox <lox@netzwerkplanet.com> wrote:<BR></DIV>
<DIV style="PADDING-LEFT: 7px; MARGIN: 0px 0px 0px 15px; BORDER-LEFT: #050505 1px solid; BACKGROUND-COLOR: #f3f3f3">Hi all.<BR><BR>We are using (or should i say "have been using"...) ocfs2 in <BR>conjunction with iscsitaget and open-iscsi.<BR><BR>Now yesterday happened what should not have happened:<BR>A colleague set up a new subversion server and remembered there was a <BR>kind of storage to use for it.<BR>He used the open-issi tools to discover the partition and used mkfs on <BR>it. So he was just fine and could continue his work. :)<BR>But:<BR>Our main fileserver lost all its data.<BR><BR>Apr 24 18:38:21 rad01 kernel: [4310373.927492] <BR>(4211,0):o2hb_do_disk_heartbeat:767 ERROR: Device "sdb": another node <BR>is heartbeating in our slot!<BR><BR>And some hours later:<BR>Apr 25 06:25:19 rad01 kernel: [4351792.508496] <BR>(1292,0):ocfs2_check_dir_entry:1778 ERROR: bad entry in directory <BR>#197799: rec_len is smaller than minimal - offset=0, inode=0, <BR>rec_len=0, name_len=0<BR><BR>When trying to mount our (formerly) ocfs2 partition:<BR><BR>root@rad01:/# mount -t ocfs2 /dev/sdb /ocfs2<BR>ocfs2_hb_ctl: Bad magic number in inode while reading uuid<BR>mount.ocfs2: Error when attempting to run /sbin/ocfs2_hb_ctl: <BR>"Operation not permitted"<BR><BR>This is on ubuntu 7.10, Linux rad01 2.6.22-14-server #1 SMP Sun Oct 14 <BR>23:34:23 GMT 2007 i686 GNU/Linux<BR><BR>Any chance to recover the data?<BR><BR>Thanks in advance,<BR>Christian<BR><BR><BR>_______________________________________________<BR>Ocfs2-users mailing list<BR>Ocfs2-users@oss.oracle.com<BR><A href="http://oss.oracle.com/mailman/listinfo/ocfs2">http://oss.oracle.com/mailman/listinfo/ocfs2</A>-users<BR></DIV>
<DIV><P><HR>
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
</P></DIV>
</BODY></HTML>