linux.git/fs/super.c, branch v2.6.34

fs: fs/super.c needs to include backing-dev.h for !CONFIG_BLOCK

2010-04-29T18:33:35+00:00

When CONFIG_BLOCK is set, it ends up getting backing-dev.h included.
But for !CONFIG_BLOCK, it isn't so lucky. The proper thing to do is
include  directly from the file it's used from,
so do that.

Signed-off-by: Jens Axboe

Catch filesystems lacking s_bdi

2010-04-25T06:54:42+00:00

noop_backing_dev_info is used only as a flag to mark filesystems that
don't have any backing store, like tmpfs, procfs, spufs, etc.

Signed-off-by: Joern Engel 

Changed the BUG_ON() to a WARN_ON(). Note that adding dirty inodes
to the noop_backing_dev_info is not legal and will not result in
them being flushed, but we already catch this condition in
__mark_inode_dirty() when checking for a registered bdi.

Signed-off-by: Jens Axboe

Mirror MS_KERNMOUNT in ->mnt_flags

2010-03-03T19:08:00+00:00

Signed-off-by: Al Viro

fs: improve remount,ro vs buffercache coherency

2010-03-03T18:00:20+00:00

Invalidate sb->s_bdev on remount,ro.

Fixes a problem reported by Jorge Boncompte who is seeing corruption
trying to snapshot a minix filesystem image.  Some filesystems modify
their metadata via a path other than the bdev buffer cache (eg.  they may
use a private linear mapping for their metadata, or implement directories
in pagecache, etc).  Also, file data modifications usually go to the bdev
via their own mappings.

These updates are not coherent with buffercache IO (eg.  via /dev/bdev)
and never have been.  However there could be a reasonable expectation that
after a mount -oremount,ro operation then the buffercache should
subsequently be coherent with previous filesystem modifications.

So invalidate the bdev mappings on a remount,ro operation to provide a
coherency point.

The problem was exposed when we switched the old rd to brd because old rd
didn't really function like a normal block device and updates to rd via
mappings other than the buffercache would still end up going into its
buffercache.  But the same problem has always affected other "normal"
block devices, including loop.

[akpm@linux-foundation.org: repair comment layout]
Reported-by: "Jorge Boncompte [DTI2]" 
Tested-by: "Jorge Boncompte [DTI2]" 
Signed-off-by: Nick Piggin 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Al Viro

vfs: get_sb_single() - do not pass options twice

2009-12-23T19:23:43+00:00

Filesystem code usually destroys the option buffer while
parsing it. This leads to errors when the same buffer is
passed twice. In case we fill a new superblock do not call
remount.

This is needed to quite a warning that the debugfs code
causes every boot.

Cc: Miklos Szeredi 
Signed-off-by: Kay Sievers 
Signed-off-by: Greg Kroah-Hartman

freeze_bdev: grab active reference to frozen superblocks

2009-09-24T11:47:41+00:00

Currently we held s_umount while a filesystem is frozen, despite that we
might return to userspace and unlock it from a different process.  Instead
grab an active reference to keep the file system busy and add an explicit
check for frozen filesystems in remount and reject the remount instead
of blocking on s_umount.

Add a new get_active_super helper to super.c for use by freeze_bdev that
grabs an active reference to a superblock from a given block device.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Al Viro

freeze_bdev: kill bd_mount_sem

2009-09-24T11:47:39+00:00

Now that we have the freeze count there is not much reason for bd_mount_sem
anymore.  The actual freeze/thaw operations are serialized using the
bd_fsfreeze_mutex, and the only other place we take bd_mount_sem is
get_sb_bdev which tries to prevent mounting a filesystem while the block
device is frozen.  Instead of add a check for bd_fsfreeze_count and
return -EBUSY if a filesystem is frozen.  While that is a change in user
visible behaviour a failing mount is much better for this case rather
than having the mount process stuck uninterruptible for a long time.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Al Viro

vfs: change sb->s_maxbytes to a loff_t

2009-09-24T11:47:33+00:00

sb->s_maxbytes is supposed to indicate the maximum size of a file that can
exist on the filesystem.  It's declared as an unsigned long long.

Even if a filesystem has no inherent limit that prevents it from using
every bit in that unsigned long long, it's still problematic to set it to
anything larger than MAX_LFS_FILESIZE.  There are places in the kernel
that cast s_maxbytes to a signed value.  If it's set too large then this
cast makes it a negative number and generally breaks the comparison.

Change s_maxbytes to be loff_t instead.  That should help eliminate the
temptation to set it too large by making it a signed value.

Also, add a warning for couple of releases to help catch filesystems that
set s_maxbytes too large.  Eventually we can either convert this to a
BUG() or just remove it and in the hope that no one will get it wrong now
that it's a signed value.

Signed-off-by: Jeff Layton 
Cc: Johannes Weiner 
Cc: Christoph Hellwig 
Cc: Al Viro 
Cc: Robert Love 
Cc: Mandeep Singh Baines 
Signed-off-by: Andrew Morton 
Signed-off-by: Al Viro

const: mark remaining super_operations const

2009-09-22T14:17:24+00:00

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fs: Assign bdi in super_block

2009-09-16T13:18:51+00:00

We do this automatically in get_sb_bdev() from the set_bdev_super()
callback. Filesystems that have their own private backing_dev_info
must assign that in ->fill_super().

Note that ->s_bdi assignment is required for proper writeback!

Acked-by: Christoph Hellwig 
Signed-off-by: Jens Axboe