linux-toradex.git/fs/ufs, branch v2.6.19.2

[PATCH] ufs endianness annotations

2006-10-10T23:15:34+00:00

Signed-off-by: Al Viro 
Signed-off-by: Linus Torvalds

[PATCH] r/o bind mounts: unlink: monitor i_nlink

2006-10-01T07:39:30+00:00

When a filesystem decrements i_nlink to zero, it means that a write must be
performed in order to drop the inode from the filesystem.

We're shortly going to have keep filesystems from being remounted r/o between
the time that this i_nlink decrement and that write occurs.

So, add a little helper function to do the decrements.  We'll tie into it in a
bit to note when i_nlink hits zero.

Signed-off-by: Dave Hansen 
Acked-by: Christoph Hellwig 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] Streamline generic_file_* interfaces and filemap cleanups

2006-10-01T07:39:28+00:00

This patch cleans up generic_file_*_read/write() interfaces.  Christoph
Hellwig gave me the idea for this clean ups.

In a nutshell, all filesystems should set .aio_read/.aio_write methods and use
do_sync_read/ do_sync_write() as their .read/.write methods.  This allows us
to cleanup all variants of generic_file_* routines.

Final available interfaces:

generic_file_aio_read() - read handler
generic_file_aio_write() - write handler
generic_file_aio_write_nolock() - no lock write handler

__generic_file_aio_write_nolock() - internal worker routine

Signed-off-by: Badari Pulavarty 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] inode-diet: Eliminate i_blksize from the inode structure

2006-09-27T15:26:18+00:00

This eliminates the i_blksize field from struct inode.  Filesystems that want
to provide a per-inode st_blksize can do so by providing their own getattr
routine instead of using the generic_fillattr() function.

Note that some filesystems were providing pretty much random (and incorrect)
values for i_blksize.

[bunk@stusta.de: cleanup]
[akpm@osdl.org: generic_fillattr() fix]
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Adrian Bunk 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] Really ignore kmem_cache_destroy return value

2006-09-27T15:26:10+00:00

* Rougly half of callers already do it by not checking return value
* Code in drivers/acpi/osl.c does the following to be sure:

	(void)kmem_cache_destroy(cache);

* Those who check it printk something, however, slab_error already printed
  the name of failed cache.
* XFS BUGs on failed kmem_cache_destroy which is not the decision
  low-level filesystem driver should make. Converted to ignore.

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

[PATCH] fs: Conversions from kmalloc+memset to k(z|c)alloc

2006-09-27T15:26:10+00:00

Conversions from kmalloc+memset to kzalloc.

Signed-off-by: Panagiotis Issaris 
Jffs2-bit-acked-by: David Woodhouse 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ufs: truncate correction

2006-08-27T18:01:31+00:00

1) When we allocated last fragment in ufs_truncate, we read page, check
   if block mapped to address, and if not trying to allocate it.  This is
   wrong behaviour, fragment may be NOT allocated, but mapped, this
   happened because of "block map" function not checked allocated fragment
   or not, it just take address of the first fragment in the block, add
   offset of fragment and return result, this is correct behaviour in
   almost all situation except call from ufs_truncate.

2) Almost all implementation of UFS, which I can investigate have such
   "defect": if you have full disk, and try truncate file, for example 3GB
   to 2MB, and have hole in this region, truncate return -ENOSPC.  I tried
   evade from this problem, but "block allocation" algorithm is tied to
   right value of i_lastfrag, and fix of this corner case may slow down of
   ordinaries scenarios, so this patch makes behavior of "truncate"
   operations similar to what other UFS implementations do.

Signed-off-by: Evgeniy Dushistov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ufs: write to hole in big file

2006-08-27T18:01:31+00:00

On UFS, this scenario:
	open(O_TRUNC)
	lseek(1024 * 1024 * 80)
	write("A")
	lseek(1024 * 2)
	write("A")

may cause access to invalid address.

This happened because of "goal" is calculated in wrong way in block
allocation path, as I see this problem exists also in 2.4.

We use construction like this i_data[lastfrag], i_data array of pointers to
direct blocks, indirect and so on, it has ceratain size ~20 elements, and
lastfrag may have value for example 40000.

Also this patch fixes related to handling such scenario issues, wrong
zeroing metadata, in case of block(not fragment) allocation, and wrong goal
calculation, when we allocate block

Signed-off-by: Evgeniy Dushistov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ufs: handle truncated pages

2006-08-06T15:57:46+00:00

ufs_get_locked_page is called twice in ufs code, one time in ufs_truncate
path(we allocated last block), and another time when fragments are
reallocated.  In ideal world in the second case on allocation/free block
layer we should not know that things like `truncate' exists, but now with
such crutch like ufs_get_locked_page we can (or should?) skip truncated
pages.

Signed-off-by: Evgeniy Dushistov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ufs: ufs_get_locked_page() race fix

2006-08-06T15:57:46+00:00

As discussed earlier:
http://lkml.org/lkml/2006/6/28/136
this patch fixes such issue:

`ufs_get_locked_page' takes page from cache
after that `vmtruncate' takes page and deletes it from cache
`ufs_get_locked_page' locks page, and reports about EIO error.

Also because of find_lock_page always return valid page or NULL, we have no
need to check it if page not NULL.

Signed-off-by: Evgeniy Dushistov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds