gmane.linux.kernel.device-mapper.devel

Re: Announce: unlimited number of shared snapshots

Mikulas Patocka — 2008-12-04T03:27:35

This is definitely caused by snapshot overflow. See this: ms: 0 4194304 multisnapshot 28 103 524288 524281 46399 ^^^^^^^^^^^^^ It's the total and allocated number of chunks. Currently, it behaves in such a way that it prevents writing to the origin, I may add more error handling modes in the future. What exactly do you mean? Technically, you can get filesystem inconsistency in the snapshot if you take snapshot of a mounted filesystem. You should suspend the origin device with "dmsetup suspend" and resume with "dmsetup resume" it after taking the snapshot. Be aware to suspend only for brief period of time on unloaded system, as there is a deadlock possibility when running with suspended filesystem. xfs and ext3 will clean-up themselves when suspending. For ext2, there's no way to get a clean snapshot, it's ext2 design limitation, even on old snapshots you get inconsistent snapshots when snapshotting mounted ext2 filesystem. Mikulas

[PATCH] dm-log: fix return value in create_log_contextfunction

Takahiro Yasui — 2008-12-04T01:15:10

Hi, This is very trivial fix, but let me post it to improve code readability. In the current implementation, caller function does not use the return value and no action is changed. Regards, --- Takahiro Yasui Hitachi Computer Products (America) Inc. When dm_io_client_create function fails in create_log_context function, return value is set to variable r but it is not used. r should be returned. Signed-off-by: Takahiro Yasui redhat.com> --- drivers/md/dm-log.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.28-rc7/drivers/md/dm-log.c =================================================================== --- linux-2.6.28-rc7.orig/drivers/md/dm-log.c +++ linux-2.6.28-rc7/drivers/md/dm-log.c < at >< at > -461,7 +461,7 < at >< at > static int create_log_context(struct dm_ r = PTR_ERR(lc->io_req.client); DMWARN("couldn't allocate disk io client"); kfree(lc); -return -ENOMEM; +return r; } lc->disk_header = vmalloc(buf_size);

Re: [patch] leastpending_io load balancing policy

Alasdair G Kergon — 2008-12-03T23:01:40

Also look at request based multipath patch rqdm-dlb-02-queue-length-dlb.patch which addresses some but not all of those points. In particular I'd be interested in evidence as to whether repeat counts or thresholds work better. Alasdair

Re: [patch] leastpending_io load balancing policy

Alasdair G Kergon — 2008-12-03T22:08:19

repeat_count is still accepted but does nothing so I've removed it. (And how did it work with a default of (unsigned) -1 anyway - never switch path?) However, it might improve performance by reducing the amount of splitting of consecutive contiguous I/Os, so I think you should consider putting it back in and implementing it (either internally or by extending the ps interface to separate choice of path from use of path). Another alternative might be to use thresholds, and only switch path, for example, when the amount of I/O outstanding down the current path is X more than the amount down the least path or the amount down the least path falls below Y. There is useful status information (io_count) not returned to userspace, so I've added that to lpp_status(). The wrapper function lpp_select_path call adds nothing so I've collapsed it. Is there some locking missing from the end_io function because it manipulates io_count? E.g. io_count atomic with memory barrier, or caller takes the lock? How does it in

What does no_path_retry=NULL mean?

Ty! Boyack — 2008-12-03T19:26:29

I've been trying to understand what the default behavior should be if no_path_retry is not set in the multipath.conf file. The annotated version describes (somewhat) what happens with values of queue, fail, or n>0, but says the default is NULL, and does not say what behavior NULL produces. The reason for the question is a situation where a highly-available iscsi target undergoes failover from one node to another, and the iscsi initiators see all their multiple paths fail during that transition time, which takes 5-120 seconds. I had set no_path_retry to queue, thinking it would queue until the paths come back, but it seems to stop checking the path status and queue forever. Is that expected? Or should no_path_retry=queue stop queuing (but continue checking the paths) and send both queued and new requests when the paths are available again? With it set to queue it hangs all I/O requests until I restart multipathd, at which point I expect that all queued data is lost. It will stay in the queued stat

dm targets with spaces in the name

Phillip Susi — 2008-12-03T17:03:02

Is this allowed? It looks like you can create a target with a space in the name, but then you can not refer to it in a rule of another target. Specifically I am seeing a user with a dmraid setup with raid volumes using spaces in the name, and dmraid manages to create the stripe target ( /dev/mapper/foo bar ), but then can not create the linear mapping on top of it for the partition, because the table looks like it has too many arguments due to the space. So should you just avoid doing this, or should the kernel be fixed to understand quotes or backslash escapes or something to allow spaces in the target device file name?

multipath-tools ./Multipath-usage.txt ./multip ...

2008-12-02T20:24:25

CVSROOT:/cvs/dm Module name:multipath-tools Branch: RHEL5_FC6 Changes by:bmarzins< at >sourceware.org2008-12-02 20:24:24 Modified files: . : Multipath-usage.txt multipath.conf.defaults libmultipath : dict.c hwtable.c Log message: Fix for a bunch of small bugs, 457776, 470896, and 439366. These are all changes to documentation files and default configurations. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/multipath-tools/Multipath-usage.txt.diff?cvsroot=dm&only_with_tag=RHEL5_FC6&r1=1.5&r2=1.5.2.1 http://sourceware.org/cgi-bin/cvsweb.cgi/multipath-tools/multipath.conf.defaults.diff?cvsroot=dm&only_with_tag=RHEL5_FC6&r1=1.5.4.13&r2=1.5.4.14 http://sourceware.org/cgi-bin/cvsweb.cgi/multipath-tools/libmultipath/dict.c.diff?cvsroot=dm&only_with_tag=RHEL5_FC6&r1=1.17.2.8&r2=1.17.2.9 http://sourceware.org/cgi-bin/cvsweb.cgi/multipath-tools/libmultipath/hwtable.c.diff?cvsroot=dm&only_with_tag=RHEL5_FC6&r1=1.20.2.15&r2=1.20.2.16 --- multipath-tools/Multipath-usage.txt2006/06/06 18:32:43

Re: Announce: unlimited number of shared snapshots

Christoph Hellwig — 2008-12-02T07:34:43

The error message definitively looks like trying to mount a r/o snapshots without -o ro,norecovery:

Re: Announce: unlimited number of shared snapshots

Mikulas Patocka — 2008-12-02T07:05:28

Hi I fixed the ext2 bug (it was unsupported handling of buffer readahead) --- download the new version of patches from the same location. I couldn't reproduce the XFS bug. Please retry. Are you sure that you didn't try to mount the _snapshot_ as XFS? Snapshots are currently not writeable (they will be writeable in the final version), so attempting to mount the snapshot read/write would return i/o error to the filesystem and produce an error message similar to the one displayed. Thanks for testing it. Mikulas

Re: Re: [RFC][PATCH 0/4] dm-log: support multi-log devices

Takahiro Yasui — 2008-12-02T06:05:00

What happens if it is a raw device rather than dm-mirror? The I/O has not completed yet and the request has not returned to the upper layer. If system crashed at this point, no one knows which data, new or old, is on the device, and application such as database should be responsible for the transaction if necessary. In the situation on dm-mirror you asked, we do not know which mirror has the latest data, but I think that it is not a problem. Thanks, --- Takahiro Yasui Hitachi Computer Products (America) Inc.

Re: Re: [RFC][PATCH 0/4] dm-log: support multi-log devices

Takahiro Yasui — 2008-12-02T04:52:22

Yes, write I/O to all underlying mirror devices need to be completed. I understand your concern and think that there is a room to study about performance enhancement. I/O request returns to the higher level after data I/O completed, and an update of the log device is done later. I am also thinking exactly what you mentioned, and it will improve performance of dm-mirror. I am now trying to improve performance in terms of: Thanks, --- Takahiro Yasui Hitachi Computer Products (America) Inc.

Re: Calltrace in dm-snapshot in 2.6.27 kernel

Mikulas Patocka — 2008-12-02T02:10:19

Hi I don't know really what is causing it. Just try this patch. It removes a lot of dirty logic from dm-snapshots. (you might need to hand-edit the patch a little bit depending on other patches that you have applied). Mikulas dm-snapshot-rework-origin-write.patch: Rework writing to snapshot origin. The previous code selected one exception as "primary_pe", linked all other exceptions on it and used reference counting to wait until all exceptions are reallocated. This didn't work with exceptions with different chunk sizes: https://bugzilla.redhat.com/show_bug.cgi?id=182659 I removed all the complexity with exceptions linking and reference counting. Currently, bio is linked on one exception and when that exception is reallocated, the bio is retried to possibly wait for other exceptions. Signed-off-by: Mikulas Patocka redhat.com> --- drivers/md/dm-snap.c | 174 +++++++++++++++++---------------------------------- 1 file changed, 61 insertions(+), 113 deletions(-) Index: linux-2.6.28-rc5-dev

Re: [RFC][PATCH 0/4] dm-log: support multi-log devices

Phillip Susi — 2008-12-01T16:10:01

Once the IO request has been completed, the data needs to be stable on the disk. This means that either you have to wait until the data has been written to all underlying mirror devices before completing the request ( slow ) or you have to have some way of knowing which disk(s) got written to, and which ones need updated after a crash. Are you saying you take the former path? Does the entire log-data-log update cycle complete before dm completes the higher level IO request? That would maintain data integrity, but at significant cost to performance. For performance sake, don't you want to allow write requests to be completed before the log is necessarily marked as clean again? That way multiple writes to the same data zone do not require multiple log dirty/clean updates. Also for performance reasons, don't you want to allow the data to be written to only one mirror before completing the request? Then go back and do lazy synchronization?

Re: [RFC][PATCH 0/4] dm-log: support multi-log devices

Michał Mirosław — 2008-12-01T11:09:37

2008/12/1 Takahiro Yasui redhat.com>: [...] What happens if some log devices contain "dirty" and not all mirrors were written yet before a crash? How do you know which mirror has the most recent data? Are the writes to mirrors ordered somehow? Best Regards, Michal Miroslaw

Re: [RFC][PATCH 2/4] dm-log: unify rw_header toread/write_header

Takahiro Yasui — 2008-12-01T07:24:01

Oh, I'm sorry not to mention it on the patch description, but your explanation is exactly what I need to do. Thanks, Alasdair. I have removed rw_header function in my patch since the last two patches don't use it, but your improvement is fine as a separate patch. Thanks, --- Takahiro Yasui Hitachi Computer Products (America) Inc.

Re: Re: [RFC][PATCH 0/4] dm-log: support multi-log devices

Takahiro Yasui — 2008-12-01T07:00:54

log disks are updated in parallel and we do not know which disk has the latest and correct data if the system crashes during write operations on log devices. But there is no problem about it. There are two cases we need to think about. 1) Some log devices contain "clean", but mirror devices are not synchronized This case is problematic, but never happens, because data is written on mirror devices after marking log devices "dirty", and make it "clean" after write I/Os on mirror devices completed and mirrors get synchronized. 2) Some log devices contain "dirty", but mirror devices are synchronized This case may happen but is not problematic. Just data replication of the region among mirror devices will be done when the mirror is resumed. This case would also happen on the system with the current single log if the system crashes after marking a log device "dirty" and before marking it back to "clean". Thanks, --- Takahiro Yasui Hitachi Computer Products (America) Inc.

Re: Re: next-20081125: crypto hard disk gets unaccessable

Herbert Xu — 2008-12-01T04:57:49

Yes that's definitely synchronous. Cheers,

Re: Re: next-20081125: crypto hard disk gets unaccessable

Milan Broz — 2008-12-01T00:16:06

Did this work before? If so, please can you provide version where it works? It is suspend to encrypted swap? There should not be any recent change in dm-crypt related to this path, so I expect it is some bug related to suspend/resume in combination with running crypto - like corruption of some memory caused during suspend... I assume that crypto run here synchronously (not through asynchronous completion callback). Herbert - is my guess ok? (The asynchronous handling in dm-crypt was the only part changed recently.) (And I think that except crypto hw nobody uses asynchronous mode yet by default.) Milan -- mbroz< at >redhat.com

Re: next-20081125: crypto hard disk gets unaccessable

Herbert Xu — 2008-11-30T04:32:15

8b 04 0e mov (%rsi,%rcx,1),%eax So we were fed a bogus pointer by the caller. Nothing has changed in the crypto ciphers lately. Cheers,

Re: next-20081125: crypto hard disk gets unaccessable

Andrew Morton — 2008-11-30T03:29:39

(cc's added) On Fri, 28 Nov 2008 07:33:55 +0100 Nico -telmich- Schottelius schottelius.org> wrote: [lots of snippage] Either a bug in dm-crypt or in crypto core, I'd guess. I assume that 2.6.28-rc6 is OK?

Re: [RFC][PATCH 2/4] dm-log: unify rw_header toread/write_header

Alasdair G Kergon — 2008-11-28T23:37:47

Indeed. And it also removes header_to_disk() from the disk_flush() code path but doesn't mention changing that:-) I assume that's also OK because there'll always have been a resume before the flush and the data can only change during a resume? I reckon that little function improves readability/maintainability and I've left it in. http://www.kernel.org/pub/linux/kernel/people/agk/patches/2.6/editing/ dm-log-avoid-reinitialising-io_req-on-every-operation.patch Alasdair