From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757671Ab0ELU4r (ORCPT ); Wed, 12 May 2010 16:56:47 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:44496 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756199Ab0ELU4p (ORCPT ); Wed, 12 May 2010 16:56:45 -0400 Date: Wed, 12 May 2010 13:56:03 -0700 From: Andrew Morton To: Thomas Stewart Cc: linux-kernel@vger.kernel.org, Evgeniy Dushistov Subject: Re: Mounting BorderWare UFS File Systems Message-Id: <20100512135603.b0a6777b.akpm@linux-foundation.org> In-Reply-To: <20100511215300.GA22152@stewarts.org.uk> References: <20100511215300.GA22152@stewarts.org.uk> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 11 May 2010 22:53:04 +0100 Thomas Stewart wrote: > Hi, > > I recently had to recover some files from an old broken machine that was > running BorderWare Document Gateway. It's basically a drop in web server > for sharing files. From the look of the init process and using strings > on of a few files it seems to be based on FreeBSD 3.3. The process > turned out to be more difficult than I imagined, but to cut a long story > short BorderWare in their wisdom use a nonstandard magic number in their > UFS (ufstype=44bsd) file systems. Thus Linux refuses to mount the file > systems in order to recover the data. After a bit of hunting I was able > to make a quick fix to fs/ufs/super.c in order to detect the new magic > number. I don't think this needs to get into mainline, but hopefully > this will hit the archives to save anyone else the effort. Oh, I expect we'll merge it - we're crazy like that. Thanks. > I'm assume > that this number is the same for all installations. It's quite easy to > find out from ufs_fs.h. The superblock sits 8k into the block device and > the magic number its 1372 bytes into the superblock struct. > > # dd if=/dev/sda5 skip=$(( 8192 + 1372 )) bs=1 count=4 2> /dev/null | hd > 00000000 97 26 24 0f |.&$.| > # > > Here is the patch, please cc any questions or comments as I'm off list. It would be preferred if you could send us your Signed-off-by: for this change, please. It's described in Documentation/SubmittingPatches. > diff -urN linux-2.6.33.1.orig/fs/ufs/super.c linux-2.6.33.1/fs/ufs/super.c > --- linux-2.6.33.1.orig/fs/ufs/super.c 2010-05-11 20:07:08.000000000 +0100 > +++ linux-2.6.33.1/fs/ufs/super.c 2010-05-11 21:23:06.000000000 +0100 > @@ -918,6 +918,7 @@ > sbi->s_bytesex = BYTESEX_LE; > switch ((uspi->fs_magic = fs32_to_cpu(sb, usb3->fs_magic))) { > case UFS_MAGIC: > + case UFS_MAGIC_BW: > case UFS2_MAGIC: > case UFS_MAGIC_LFN: > case UFS_MAGIC_FEA: > @@ -927,6 +928,7 @@ > sbi->s_bytesex = BYTESEX_BE; > switch ((uspi->fs_magic = fs32_to_cpu(sb, usb3->fs_magic))) { > case UFS_MAGIC: > + case UFS_MAGIC_BW: > case UFS2_MAGIC: > case UFS_MAGIC_LFN: > case UFS_MAGIC_FEA: Your email client replaces tabs with spaces. I fixed that up. > diff -urN linux-2.6.33.1.orig/fs/ufs/ufs_fs.h linux-2.6.33.1/fs/ufs/ufs_fs.h > --- linux-2.6.33.1.orig/fs/ufs/ufs_fs.h 2010-03-15 16:09:39.000000000 +0000 > +++ linux-2.6.33.1/fs/ufs/ufs_fs.h 2010-05-11 21:20:35.000000000 +0100 > @@ -48,6 +48,7 @@ > #define UFS_SECTOR_SIZE 512 > #define UFS_SECTOR_BITS 9 > #define UFS_MAGIC 0x00011954 > +#define UFS_MAGIC_BW 0x0f242697 > #define UFS2_MAGIC 0x19540119 > #define UFS_CIGAM 0x54190100 /* byteswapped MAGIC */ Perhaps we should move these to magic.h. I'm not sure what benefit that would provide, really.