28 May, 2010

1 commit

  • 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 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 |.&$.|
    #

    Signed-off-by: Thomas Stewart
    Cc: Evgeniy Dushistov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Stewart
     

13 Mar, 2010

2 commits

  • Alex Viskovatoff let me know that after copying data to solaris's ufs from
    linux, solaris's fsck sees some errors in cylinder summary information.
    This is because of solaris expects find some data on another places, then
    curernt implementation save it. This patch fixes this issue. It is
    tested by me, and also Alex reported that it works for him.

    Signed-off-by: Evgeniy Dushistov
    Reported-by: Alex Viskovatoff
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Evgeniy Dushistov
     
  • Recent releases of Solaris set the fs_clean state of an unmounted UFS file
    system as FSLOG ("logging fs"). However, the Linux kernel currently does
    not recognize the value which represents this state. Thus, attempting to
    mount such a file system rw produces the message

    kernel: ufs_read_super: can't grok fs_clean 0xfffffffd

    and the file system is mounted read-only. This patch makes the kernel
    recognize that value.

    Signed-off-by: Alex Viskovatoff
    Cc: Evgeniy Dushistov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alex Viskovatoff
     

09 Feb, 2008

1 commit

  • Per previous discussions about cleaning up ufs_fs.h, people just want
    this straight up dropped from userspace export. The only remaining
    consumer (silo) has been fixed a while ago to not rely on this header.
    This allows use to move it completely from include/linux/ to fs/ufs/
    seeing as how the only in-kernel consumer is fs/ufs/.

    Signed-off-by: Mike Frysinger
    Cc: Jan Kara
    Cc: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mike Frysinger