An error occurred fetching the project authors.
- 24 May, 2007 1 commit
-
-
NeilBrown authored
It is possible that real data or metadata follows the bitmap without full page alignment. So limit the last write to be only the required number of bytes, rounded up to the hard sector size of the device. Signed-off-by:
Neil Brown <neilb@suse.de> Cc: <stable@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 08 May, 2007 1 commit
-
-
Mark Fasheh authored
Remove do_sync_file_range() and convert callers to just use do_sync_mapping_range(). Signed-off-by:
Mark Fasheh <mark.fasheh@oracle.com> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
-
- 12 Apr, 2007 1 commit
-
-
Neil Brown authored
If 'num_pages' were ever 1 more than a multiple of 8 (32bit platforms) or of 16 (64 bit platforms). filemap_attr would be allocated one 'unsigned long' shorter than required. We need a round-up in there. Signed-off-by:
-
- 11 Feb, 2007 1 commit
-
-
Andrew Morton authored
Convert all calls to invalidate_inode_pages() into open-coded calls to invalidate_mapping_pages(). Leave the invalidate_inode_pages() wrapper in place for now, marked as deprecated. Signed-off-by:
-
- 09 Feb, 2007 1 commit
-
-
Neil Brown authored
md/bitmap tracks how many active write requests are pending on blocks associated with each bit in the bitmap, so that it knows when it can clear the bit (when count hits zero). The counter has 14 bits of space, so if there are ever more than 16383, we cannot cope. Currently the code just calles BUG_ON as "all" drivers have request queue limits much smaller than this. However is seems that some don't. Apparently some multipath configurations can allow more than 16383 concurrent write requests. So, in this unlikely situation, instead of calling BUG_ON we now wait for the count to drop down a bit. This requires a new wait_queue_head, some waiting code, and a wakeup call. Tested by limiting the counter to 20 instead of 16383 (writes go a lot slower in that case...). Signed-off-by:
-
- 26 Jan, 2007 1 commit
-
-
NeilBrown authored
In most cases we check the size of the bitmap file before reading data from it. However when reading the superblock, we always read the first PAGE_SIZE bytes, which might not always be appropriate. So limit that read to the size of the file if appropriate. Also, we get the count of available bytes wrong in one place, so that too can read past the end of the file. Cc: "yang yin" <yinyang801120@gmail.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
- 08 Dec, 2006 1 commit
-
-
Josef Sipek authored
Signed-off-by:
Josef Sipek <jsipek@fsl.cs.sunysb.edu> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
- 21 Oct, 2006 1 commit
-
-
NeilBrown authored
And a couple of bug fixes found by sparse. Signed-off-by:
-
- 11 Oct, 2006 1 commit
-
-
Alexey Dobriyan authored
Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Acked-by:
-
- 03 Oct, 2006 2 commits
-
-
Paul Clements authored
find_first_set doesn't find the least-significant bit on bigendian machines, so it is really wrong to use it. ffs is closer, but takes an 'int' and we have a 'unsigned long'. So use ffz(~X) to convert a chunksize into a chunkshift. Signed-off-by:
-
Paul Clements authored
Add a new sysfs interface that allows the bitmap of an array to be dirtied. The interface is write-only, and is used as follows: echo "1000" > /sys/block/md2/md/bitmap (dirty the bit for chunk 1000 [offset 0] in the in-memory and on-disk bitmaps of array md2) echo "1000-2000" > /sys/block/md1/md/bitmap (dirty the bits for chunks 1000-2000 in md1's bitmap) This is useful, for example, in cluster environments where you may need to combine two disjoint bitmaps into one (following a server failure, after a secondary server has taken over the array). By combining the bitmaps on the two servers, a full resync can be avoided (This was discussed on the list back on March 18, 2005, "[PATCH 1/2] md bitmap bug fixes" thread). Signed-off-by:
-
- 30 Jun, 2006 1 commit
-
-
Jörn Engel authored
Signed-off-by:
Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by:
Adrian Bunk <bunk@stusta.de>
-
- 26 Jun, 2006 8 commits
-
-
NeilBrown authored
Fix problems with new bmap based access to bitmap files. 1/ When not using a file based bitmap, attach a NULL list of buffers to each page so the common free_buffer routine can cope. 2/ Use submit_bh to read as well as write, rather than vfs_read. This makes read and write more symetric. 3/ sync the file before reading, to ensure that the page cache has no dirty pages that might get written out later. Signed-off-by:
-
NeilBrown authored
If md is asked to store a bitmap in a file, it tries to hold onto the page cache pages for that file, manipulate them directly, and call a cocktail of operations to write the file out. I don't believe this is a supportable approach. This patch changes the approach to use the same approach as swap files. i.e. bmap is used to enumerate all the block address of parts of the file and we write directly to those blocks of the device. swapfile only uses parts of the file that provide a full pages at contiguous addresses. We don't have that luxury so we have to cope with pages that are non-contiguous in storage. To handle this we attach buffers to each page, and store the addresses in those buffers. With this approach the pagecache may contain data which is inconsistent with what is on disk. To alleviate the problems this can cause, md invalidates the pagecache when releasing the file. If the file is to be examined while the array is active (a non-critical but occasionally useful function), O_DIRECT io must be used. And new version of mdadm will have support for this. This approach simplifies a lot of code: - we no longer need to keep a list of pages which we need to wait for, as the b_endio function can keep track of how many outstanding writes there are. This saves a mempool. - -EAGAIN returns from write_page are no longer possible (not sure if they ever were actually). Signed-off-by: -
NeilBrown authored
md/bitmap modifies i_writecount of a bitmap file to make sure that no-one else writes to it. The reverting of the change is sometimes done twice, and there is one error path where it is omitted. This patch tidies that up. Signed-off-by:
-
NeilBrown authored
bitmap_active is never called, and the BITMAP_ACTIVE flag is never users or tested, so discard them both. Also remove some out-of-date 'todo' comments. Signed-off-by:
-
NeilBrown authored
md/bitmap gets a collection of pages representing the bitmap when it initialises the bitmap, and puts all the references when discarding the bitmap. It also occasionally takes extra references without any good reason, and sometimes drops them ... though it doesn't always drop them, which can result in a memory leak. This patch removes the unnecessary 'get_page' calls, and the corresponding 'put_page' calls. Signed-off-by:
-
NeilBrown authored
In particular, this means that we use 4 bits per page instead of a whole unsigned long. Signed-off-by:
-
NeilBrown authored
md/bitmap has some attributes per-page. Handling of these attributes in largely abstracted in set_page_attr and clear_page_attr. However get_page_attr exposes the format used to store them. So prior to changing that format, introduce test_page_attr instead of get_page_attr, and make appropriate usage changes. Signed-off-by:
-
NeilBrown authored
md/bitmap currently has a separate thread to wait for writes to the bitmap file to complete (as we cannot get a callback on that action). However this isn't needed as bitmap_unplug is called from process context and waits for the writeback thread to do it's work. The same result can be achieved by doing the waiting directly in bitmap_unplug. Signed-off-by:
-
- 26 Mar, 2006 1 commit
-
-
Matthew Dobson authored
This patch changes several mempool users, all of which are basically just wrappers around kmalloc(), to use the common mempool_kmalloc/kfree, rather than their own wrapper function, removing a bunch of duplicated code. Signed-off-by:
Matthew Dobson <colpatch@us.ibm.com> Signed-off-by:
-
- 25 Mar, 2006 1 commit
-
-
Adrian Bunk authored
We dereference bitmap both one line above and one line below this check rendering this check quite useless. Spotted by the Coverity checker. Signed-off-by:
-
- 24 Mar, 2006 1 commit
-
-
Eric Sesterhenn authored
this changes if() BUG(); constructs to BUG_ON() which is cleaner and can better optimized away Signed-off-by:
Eric Sesterhenn <snakebyte@gmx.de> Signed-off-by:
-
- 15 Jan, 2006 1 commit
-
-
Arjan van de Ven authored
Remove the "inline" keyword from a bunch of big functions in the kernel with the goal of shrinking it by 30kb to 40kb Signed-off-by:
Arjan van de Ven <arjan@infradead.org> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Acked-by:
Jeff Garzik <jgarzik@pobox.com> Signed-off-by:
-
- 06 Jan, 2006 7 commits
-
-
NeilBrown authored
When we update a page_cache page in the kernel, we need to flush_dache_page or userspace might not see the change. Signed-off-by:
-
NeilBrown authored
md sometimes call put_page on NULL pointers (treating it like kfree). This is not safe, so define and use a 'safe_put_page' which checks for NULL. Signed-off-by:
-
NeilBrown authored
The kernel should not be imposing these policy limits: The time between bitmap updates should certainly be allowed to be more than 15 seconds, and if someone wants a bitmap chunk size in excess of 4MB, the kernel isn't the place to stop them. Signed-off-by:
-
NeilBrown authored
Signed-off-by:
-
NeilBrown authored
Replace multiple kmalloc/memset pairs with kzalloc calls. Signed-off-by:
-
NeilBrown authored
Substitute: page_cache_get -> get_page page_cache_release -> put_page PAGE_CACHE_SHIFT -> PAGE_SHIFT PAGE_CACHE_SIZE -> PAGE_SIZE PAGE_CACHE_MASK -> PAGE_MASK __free_page -> put_page because we aren't using the page cache, we are just using pages. Signed-off-by:
-
NeilBrown authored
This is important because bitmap_create uses mddev->resync_max_sectors and that doesn't have a valid value until after the array has been initialised (with pers->run()). [It doesn't make a difference for current personalities that support bitmaps, but will make a difference for raid10] This has the added advantage of meaning with can move the thread->timeout manipulation inside the bitmap.c code instead of sprinkling identical code throughout all personalities. Signed-off-by:
-
- 18 Nov, 2005 1 commit
-
-
Neil Brown authored
Some filesystems go oops. Signed-off-by:
-
- 09 Nov, 2005 4 commits
-
-
NeilBrown authored
We can only accept BARRIER requests if all slaves handle barriers, and that can, of course, change with time.... So we keep track of whether the whole array seems safe for barriers, and also whether each individual rdev handles barriers. We initially assumes barriers are OK. When writing the superblock we try a barrier, and if that fails, we flag things for no-barriers. This will usually clear the flags fairly quickly. If writing the superblock finds that BIO_RW_BARRIER is -ENOTSUPP, we need to resubmit, so introduce function "md_super_wait" which waits for requests to finish, and retries ENOTSUPP requests without the barrier flag. When writing the real raid1, write requests which were BIO_RW_BARRIER but which aresn't supported need to be retried. So raid1d is enhanced to do this, and when any bio write completes (i.e. no retry needed) we remove it from the r1bio, so that devices needing retry are easy to find. We should hardly ever get -ENOTSUPP errors when writing data to the raid. It should only happen if: 1/ the device used to support BARRIER, but now doesn't. Few devices change like this, though raid1 can! or 2/ the array has no persistent superblock, so there was no opportunity to pre-test for barriers when writing the superblock. Signed-off-by:Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by:
-
NeilBrown authored
Current bitmaps use set_bit et.al and so are host-endian, which means not-portable. Oops. Define a new version number (4) for which bitmaps are little-endian. Signed-off-by:
-
NeilBrown authored
This has the advantage of removing the confusion caused by 'rdev_t' and 'mddev_t' both having 'in_sync' fields. Signed-off-by:
-
Olaf Hering authored
This patch removes almost all inclusions of linux/version.h. The 3 #defines are unused in most of the touched files. A few drivers use the simple KERNEL_VERSION(a,b,c) macro, which is unfortunatly in linux/version.h. There are also lots of #ifdef for long obsolete kernels, this was not touched. In a few places, the linux/version.h include was move to where the LINUX_VERSION_CODE was used. quilt vi `find * -type f -name "*.[ch]"|xargs grep -El '(UTS_RELEASE|LINUX_VERSION_CODE|KERNEL_VERSION|linux/version.h)'|grep -Ev '(/(boot|coda|drm)/|~$)'` search pattern: /UTS_RELEASE\|LINUX_VERSION_CODE\|KERNEL_VERSION\|linux\/\(utsname\|version\).h Signed-off-by:
Olaf Hering <olh@suse.de> Signed-off-by:
-
- 28 Oct, 2005 1 commit
-
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
- 09 Sep, 2005 3 commits
-
-
NeilBrown authored
The bitmap code used to have two daemons, so there is some 'common' start/stop code. But now there is only one, so the common code is just noise. This patch tidies this up somewhat. Signed-off-by:
-
NeilBrown authored
mddev->bitmap gets clearred before the writeback daemon is stopped. So the write_back daemon needs to be careful not to dereference the 'bitmap' if it is NULL. Signed-off-by:
-
NeilBrown authored
read_sb_page() assumed that if sync_page_io fails, the device would be marked faultly. However it isn't. So in the face of error, read_sb_page would loop forever. Redo the logic so that this cannot happen. Signed-off-by:
-
