Commit Graph

5 Commits

Author SHA1 Message Date
Artem Bityutskiy
9e9ad5f408 fs/ufs: get rid of write_super
This patch makes UFS stop using the VFS '->write_super()' method along with
the 's_dirt' superblock flag, because they are on their way out.

The way we implement this is that we schedule a delay job instead relying on
's_dirt' and '->write_super()'.

The whole "superblock write-out" VFS infrastructure is served by the
'sync_supers()' kernel thread, which wakes up every 5 (by default) seconds and
writes out all dirty superblocks using the '->write_super()' call-back.  But the
problem with this thread is that it wastes power by waking up the system every
5 seconds, even if there are no diry superblocks, or there are no client
file-systems which would need this (e.g., btrfs does not use
'->write_super()'). So we want to kill it completely and thus, we need to make
file-systems to stop using the '->write_super()' VFS service, and then remove
it together with the kernel thread.

Tested using fsstress from the LTP project.

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2012-07-22 23:58:16 +04:00
Thomas Stewart
d27d7a9a78 ufs: permit mounting of BorderWare filesystems
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 <thomas@stewarts.org.uk>
Cc: Evgeniy Dushistov <dushistov@mail.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-05-27 09:12:43 -07:00
Evgeniy Dushistov
ad25ad979a ufs: make solaris fsck happy
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 <dushistov@mail.ru>
Reported-by: Alex Viskovatoff <viskovatoff@imap.cc>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-03-12 15:52:35 -08:00
Alex Viskovatoff
b3a0fd4d87 fs/ufs: recognize Solaris-specific file system state
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 <viskovatoff@imap.cc>
Cc: Evgeniy Dushistov <dushistov@mail.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-03-12 15:52:35 -08:00
Mike Frysinger
e542059884 drop linux/ufs_fs.h from userspace export and relocate it to fs/ufs/ufs_fs.h
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 <vapier@gentoo.org>
Cc: Jan Kara <jack@ucw.cz>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-08 09:22:39 -08:00