aboutsummaryrefslogtreecommitdiff
path: root/drivers/md/dm-log.c
AgeCommit message (Collapse)Author
2008-02-08dm log: auto load modulesJonathan Brassow
If the log type is not recognised, attempt to load the module 'dm-log-<type>.ko'. Signed-off-by: Jonathan Brassow <jbrassow@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2007-10-20dm log: split suspendJonathan Brassow
There are now two phases to a suspend in device-mapper - presuspend and postsuspend. This patch removes the single 'suspend' in the logging API and replaces it with 'presuspend' and 'postsuspend' functions to align it better with core device-mapper. A subsequent patch will make use of 'presuspend'. Signed-off-by: Jonathan Brassow <jbrassow@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2007-05-09dm log: fix resume failed log deviceJonathan Brassow
This patch removes the possibility of having uninitialized log state if the log device has failed. When a mirror resumes operation, it calls 'resume' on the logging module. If disk based logging is being used, the log device is read to fill in the log state. If the log device has failed, we cannot simply return, because this would leave the in-memory log state uninitialized. Instead, we assume all regions are out-of-sync and reset the log state. Failure to do this could result in the logging code reporting a region as in-sync, even though it isn't; which could result in a corrupted mirror. Signed-off-by: Jonathan Brassow <jbrassow@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-09dm log: update dm io interfaceHeinz Mauelshagen
This patch ports dm-log.c to the new dm-io interface in order to make it scalable to have a large number of persistent dirty logs active in parallel. Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com> Cc: Milan Broz <mbroz@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-09dm log: report fault statusJonathan E Brassow
This patch reports the status of the log device so that userspace can detect the error and take appropriate action. Signed-off-by: Jonathan E Brassow <jbrassow@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-09dm log: fault detectionJonathan E Brassow
This patch gives the disk logging code the ability to store the fact that an error occured on the log device. In addition, an event is raised when an error is encountered during I/O to the log device. Signed-off-by: Jonathan E Brassow <jbrassow@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2006-12-08[PATCH] dm: raid1: reset sync_search on resumeJonathan E Brassow
Reset sync_search on resume. The effect is to retry syncing all out-of-sync regions when a mirror is resumed, including ones that previously failed. Signed-off-by: Jonathan E Brassow <jbrassow@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Cc: dm-devel@redhat.com Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-08[PATCH] dm: log: rename complete_resync_workJonathan E Brassow
The complete_resync_work function only provides the ability to change an out-of-sync region to in-sync. This patch enhances the function to allow us to change the status from in-sync to out-of-sync as well, something that is needed when a mirror write to one of the devices or an initial resync on a given region fails. Signed-off-by: Jonathan E Brassow <jbrassow@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Cc: dm-devel@redhat.com Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] dm: improve error message consistencyAlasdair G Kergon
Tidy device-mapper error messages to include context information automatically. Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] dm mirror log: sync_count fixAlasdair G Kergon
When a mirror is reduced in size, clear the part of the bitmap that is no longer used. Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] dm mirror log: bitset_size fixAlasdair G Kergon
Fix the 'sizeof' in the region log bitmap size calculation: it's uint32_t, not unsigned long - this breaks on some archs. Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] dm mirror log: refactor contextAlasdair G Kergon
Refactor the code that creates the core and disk log contexts to avoid the repeated allocation of clean_bits introduced by the last patch. Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] dm mirror log: sector size fixKevin Corry
On-disk logs for dm-mirror devices are currently hard-coded to use 512 byte hard-sector-sizes. This patch fixes dm-log so it will work with devices with non-512-byte hard-sector-sizes. To maintain full compatibility, instead of moving the clean-bits bitset to a bitset, and enlarges the disk-header buffer to encompass both the header and the bitset. The I/O routines for the bitset are removed, and the I/O routines for the disk-header now also read/write the bitset. Signed-off-by: Kevin Corry <kevcorry@us.ibm.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-02[PATCH] device-mapper log bitset: fix big endian find_next_zero_bitStefan Bader
This is a fix to the device-mapper-log-bitset-fix-endian patch that switched to ext2_* versions of the set and clear bit functions. The find_next_zero_bit function also has to be the ext2 one. Otherwise the mirror target tries to recover non-existent regions beyond the end of device. Signed-off-by: Stefan Bader <shbader@de.ibm.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-01[PATCH] device-mapper log bitset: fix endianPatrick Caulfield
Clean up the code responsible for the on-disk mirror logs by using the set_le_bit test_le_bit functions of ext2. That makes the BE machines keep the bitmap internally in LE order - it does mean you can't use any other type of operations on the bitmap words but that looks to be OK in this instance. The efficiency tradeoff is very minimal as you would expect for something that ext2 uses. This allows us to remove bits_to_core(), bits_to_disk() and log->disk_bits. Also increment the mirror log disk version transparently to avoid sharing with older kernels that suffered from the 64-bit BE bug. Signed-off-by: Patrick Caulfield <pcaulfie@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-06[PATCH] make dm-mirror not issue invalid resync requestsDarrick J. Wong
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: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-22[PATCH] device-mapper: mirror log bitset fixAlasdair G Kergon
The linux bitset operators (test_bit, set_bit etc) work on arrays of "unsigned long". dm-log uses such bitsets but treats them as arrays of uint32_t, only allocating and zeroing a multiple of 4 bytes (as 'clean_bits' is a uint32_t). The patch below fixes this problem. The problem is specific to 64-bit big endian machines such as s390x or ppc-64 and can prevent pvmove terminating. In the simplest case, if "region_count" were (say) 30, then bitset_size (below) would be 4 and bitset_uint32_count would be 1. Thus the memory for this butset, after allocation and zeroing would be 0 0 0 0 X X X X On a bigendian 64bit machine, bit 0 for this bitset is in the 8th byte! (and every bit that dm-log would use would be in the X area). 0 0 0 0 X X X X ^ here which hasn't been cleared properly. As the dm-raid1 code only syncs and counts regions which have a 0 in the 'sync_bits' bitset, and only finishes when it has counted high enough, a large number of 1's among those 'X's will cause the sync to not complete. It is worth noting that the code uses the same bitsets for in-memory and on-disk logs. As these bitsets are host-endian and host-sized, this means that they cannot safely be moved between computers with Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!