- 06 Jan, 2006 40 commits
-
-
NeilBrown authored
Resync code: A test that isn't needed, a 'compute_block' that makes more sense elsewhere (And then doesn't need a test), a couple of BUG_ONs to confirm the change makes sense. Printks: A few were missing KERN_* Also fix a typo in a comment.. Signed-off-by:Neil Brown <neilb@suse.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
NeilBrown authored
raid10 needs to put up a barrier to new requests while it does resync or other background recovery. The code for this is currently open-coded, slighty obscure by its use of two waitqueues, and not documented. This patch gathers all the related code into 4 functions, and includes a comment which (hopefully) explains what is happening. Signed-off-by:
-
NeilBrown authored
raid1 needs to put up a barrier to new requests while it does resync or other background recovery. The code for this is currently open-coded, slighty obscure by its use of two waitqueues, and not documented. This patch gathers all the related code into 4 functions, and includes a comment which (hopefully) explains what is happening. Signed-off-by:
-
Darrick J. Wong authored
I've been attempting to set up a (Host)RAID mirror with dm_mirror on 2.6.14.3, and I've been having a strange little problem. The configuration in question is a set of 9GB SCSI disks that have 17942584 sectors. I set up the dm_mirror table as such: 0 17942528 mirror core 2 2048 nosync 2 8:48 0 8:64 0 If I'm not mistaken, this sets up a 9GB RAID1 mriror with 1MB stripes across both SCSI disks. The sector count of the dm device is less than the size of the disks, so we shouldn't fall off the end. However, I always get the messages like this in dmesg when I set up the dm table: attempt to access beyond end of device sdd: rw=0, want=17958656, limit=17942584 Clearly, something is trying to read sectors past the end of the drive. I traced it down to the __rh_recovery_prepare function in dm-raid1.c, which gets called when we're putting the mirror set together. This function calls the dirty region log's get_resync_work function to see if there's any resync that needs to be done, and queues up any areas that are out of sync. The log's get_resync_work function is actually a pointer to the core_get_resync_work function in dm-log.c. The core_get_resync_work function queries a bitset lc->sync_bits to find out if there are any regions that are out of date (i.e. the bit is 0), which is where the problem occurs. If every bit in lc->sync_bits is 1 (which is the case when we've just configured a new RAID1 with the nosync option), the find_next_zero_bit does NOT return the size parameter (lc->region_count in this case), it returns the size parameter rounded up to the nearest multiple of 32! I don't know if this is intentional, but i386 and x86_64 both exhibit this behavior. In any case, the statement "if (*region == lc->region_count)" looks like it's supposed to catch the case where are no regions to resync and return 0. Since find_next_zero_bit apparently has a habit of returning a value that's larger than lc->region_count, the enclosed patch changes the equality test to a greater-than test so that we don't try to resync areas outside of the RAID1 region. Seeing as the HostRAID metadata lives just past the end of the RAID1 data, mucking around in that area is not a good idea. I suppose another way to fix this would be to amend find_next_zero_bit so that it doesn't return values larger than "size", but I don't know if there's a reason for the current behavior. Signed-Off-By:
Darrick J. Wong <djwong@us.ibm.com> Acked-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
-
Stefan Rompf authored
Zap the memory before freeing it so we don't leave crypto information around in memory. Signed-off-by:
Stefan Rompf <stefan@loplof.de> Acked-by:
Clemens Fruhwirth <clemens@endorphin.org> Acked-by:
-
Adrian Bunk authored
This patch #if 0's the not yet implemented global function kcopyd_cancel(). Signed-off-by:
Adrian Bunk <bunk@stusta.de> Acked-by:
-
Alasdair G Kergon authored
Add ioctl DM_SKIP_LOCKFS_FLAG for userspace to request that lock_fs is bypassed when suspending a device. There's no change to the behaviour of existing code that doesn't know about the new flag. Signed-off-by:
-
Alasdair G Kergon authored
Devices only needs syncing when creating snapshots, so make this optional when suspending a device. Signed-off-by:
-
Alasdair G Kergon authored
Rename frozen_bdev to suspended_bdev and move the bdget outside lockfs. (This prepares for making lockfs optional.) Signed-off-by:
-
Jonathan E Brassow authored
This patch introduces a new field to the mirror_set (default_mirror) to store the default mirror. (A subsequent patch will allow us to change the default mirror in the event of a failure.) Signed-off-by:
-
Alasdair G Kergon authored
Use %llu not %Lu in sscanf/printf format strings. Signed-off-by:
-
Andrew Stribblehill authored
This patch removes an unused #define. Signed-off-by:
-
Alasdair G Kergon authored
More snapshot metadata reading into separate function, to prepare for changing the place it gets called from. Signed-off-by:
-
goggin, edward authored
After changing the name of a mapped device, trigger a dm event. (For userspace multipath tools.) Signed-off-by:
-
David Teigland authored
Add dm_get_dev() to get a mapped device given its dev_t. Signed-off-by:
-
David Teigland authored
Abstract dm_find_md() from dm_get_mdptr() to allow use elsewhere. Signed-off-by:
-
Neil Brown authored
A typical nfsd call trace is nfsd -> svc_process -> nfsd_dispatch -> nfsd3_proc_write -> nfsd_write ->nfsd_vfs_write -> vfs_writev These add up to over 300 bytes on the stack. Looking at each of these, I see that nfsd_write (which includes nfsd_vfs_write) contributes 0x8c to stack usage itself!! It turns out this is because it puts a 'struct iattr' on the stack so it can kill suid if needed. The following patch saves about 50 bytes off the stack in this call path. Signed-off-by:
-
David Shaw authored
Both vfs_getattr and i_op->fsync return error statuses which nfsd was largely ignoring. This as noticed when exporting directories using fuse. This patch cleans up most of the offences, which involves moving the call to vfs_getattr out of the xdr encoding routines (where it is too late to report an error) into the main NFS procedure handling routines. There is still a called to vfs_gettattr (related to the ACL code) where the status is ignored, and called to nfsd_sync_dir don't check return status either. Signed-off-by:
-
Olaf Kirch authored
I submitted this one previously - svc_tcp_recvfrom currently returns any errors to the caller, including ECONNRESET and the like. This is something svc_recv isn't able to deal with: len = svsk->sk_recvfrom(rqstp); [...] if (len == 0 || len == -EAGAIN) { [...] return -EAGAIN; } [...] return len; The nfsd main loop will exit when it sees an error code other than EAGAIN. The following patch fixes this problem svc_recv is not equipped to deal with error codes other than EAGAIN, and will propagate anything else (such as ECONNRESET) up to nfsd, causing it to exit. Signed-off-by:Olaf Kirch <okir@suse.de> Cc: Trond Myklebust <trond.myklebust@fys.uio.no> Cc: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by:
-
Jan Kara authored
Split the checkpoint list of the transaction into two lists. In the first list we keep the buffers that need to be submitted for IO. In the second list are kept buffers that were already submitted and we just have to wait for the IO to complete. This should simplify a handling of checkpoint lists a bit and can eventually be also a performance gain. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Jayachandran C authored
This patch fixes an issue reported by Coverity in kernel/module.c Error reported: Cannot reach this line of code "else return ptr;" Patch description: This is the error path, so 'err' will be negative, the else case is not required, this patch removes it. Signed-off-by:
Jayachandran C. <c.jayachandran@gmail.com> Signed-off-by:
-
Paul E. McKenney authored
I missed a use of list_for_each_rcu_safe() in -mm tree. Here is an updated patch to fix it. This time tested on a machine that actually uses IPMI... (Thanks to Serge Hallyn for spotting this.) Signed-off-by:
"Paul E. McKenney" <paulmck@us.ibm.com> Cc: Corey Minyard <minyard@acm.org> Cc: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by:
-
Adrian Bunk authored
"extern inline" doesn't make much sense. Signed-off-by:
-
Adrian Bunk authored
Unless I miss something, this should be the simplest way to express the intended dependencies. Signed-off-by:
-
Marko Kohtala authored
Help external ppSCSI driver by exporting parport_get_port to match the parport_put_port. Signed-off-by:
Marko Kohtala <marko.kohtala@gmail.com> Signed-off-by:
-
Marko Kohtala authored
Small cleanup of includes meant for older implementation. Signed-off-by:
-
Marko Kohtala authored
Make drivers that use directly PC parport HW depend on PARPORT_PC rather than HW independent PARPORT. Signed-off-by:
-
Marko Kohtala authored
Add missing "struct" keyword preventing compilation with DEBUG_PARPORT defined. Also add some "const". Signed-off-by:
-
Marko Kohtala authored
Trivial "const" additions to places in parport that truly are const. Signed-off-by:
-
Marko Kohtala authored
Use the complete slab buffer that is allocated by kmalloc. Signed-off-by:
-
Marko Kohtala authored
parport_daisy_select returned wrong status that is read at wrong time during daisy command execution. Signed-off-by:
-
Marko Kohtala authored
Device ID reading from daisy chain devices failed because the daisy device could not be opened. Signed-off-by:
-
Marko Kohtala authored
Daisy chain end detection failed at least with older daisy chain devices that do not implement the last device signal. Signed-off-by:
-
Marko Kohtala authored
Did not move the parport interface properly into IEEE1284_PH_REV_IDLE phase at end of data due to comparing bytes with nibbles. Internal phase IEEE1284_PH_HBUSY_DNA became unused, so remove it. Signed-off-by:
-
Marko Kohtala authored
Fix potential buffer overflow in case the device ID did not end in semicolon. Also might fail to negotiate back to IEEE1284_MODE_COMPAT in case of failure. parport_device_id did not return what Documentation/parport-lowlevel.txt said, so I changed it to match it. Determining device ID length is overly complicated, but Tim Waugh recalled on linux-parport seeing some buggy device that might need it. Signed-off-by:
-
Miklos Szeredi authored
Previously invalid types were quietly changed to regular files, but at revalidation the inode was changed to bad. This was rather inconsistent behavior. Now check if the type is valid on initial lookup, and return -EIO if not. Signed-off-by:
Miklos Szeredi <miklos@szeredi.hu> Signed-off-by:
-
Miklos Szeredi authored
In direct_io mode, send at least one page per reqest. Previously it was possible that reqests with zero data were sent, and hence the read/write didn't make any progress, resulting in an infinite (though interruptible) loop. Signed-off-by:
-
Miklos Szeredi authored
Make the maximum size of write data configurable by the filesystem. The previous fixed 4096 limit only worked on architectures where the page size is less or equal to this. This change make writing work on other architectures too, and also lets the filesystem receive bigger write requests in direct_io mode. Normal writes which go through the page cache are still limited to a page sized chunk per request. Signed-off-by:
-
Miklos Szeredi authored
Change the way a too large request is handled. Until now in this case the device read returned -EINVAL and the operation returned -EIO. Make it more flexibible by not returning -EINVAL from the read, but restarting it instead. Also remove the fixed limit on setxattr data and let the filesystem provide as large a read buffer as it needs to handle the extended attribute data. The symbolic link length is already checked by VFS to be less than PATH_MAX, so the extra check against FUSE_SYMLINK_MAX is not needed. The check in fuse_create_open() against FUSE_NAME_MAX is not needed, since the dentry has already been looked up, and hence the name already checked. Signed-off-by:
-
Miklos Szeredi authored
Make file operations on a bad inode fail. This just makes things a bit more consistent. Signed-off-by:
-
