* Resync of the degraded RAID10 array
From: Tomasz Majchrzak @ 2017-05-10 14:00 UTC (permalink / raw)
To: linux-raid
Hi all,
I wonder what should be the resync behaviour for the degraded RAID10 array.
cat /proc/mdstat
Personalities : [raid10]
md127 : active raid10 nvme3n1[3] nvme2n1[2] nvme1n1[1] nvme0n1[0]
2097152 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
[==>..................] resync = 11.0% (232704/2097152) finish=0.1min speed=232704K/sec
mdadm -If nvme3n1
mdadm: set nvme3n1 faulty in md127
mdadm: hot removed nvme3n1 from md127
cat /proc/mdstat
Personalities : [raid10]
md127 : active (auto-read-only) raid10 nvme2n1[2] nvme1n1[1] nvme0n1[0]
2097152 blocks super 1.2 512K chunks 2 near-copies [4/3] [UUU_]
resync=PENDING
cat /sys/block/md127/md/resync_start
465408
At the moment it stops the resync. When new disk is added to the array, the
recovery starts and completes, however no resync for the first 2 disks takes
place and array is reported as clean when it's really out-of-sync.
My kernel version is 4.11.
What is the expected behaviour? Shall resync continue on 3-disk RAID10 or
shall it be restarted when recovery completes?
Regards,
Tomek
^ permalink raw reply
* Re: [PATCH 25/27] block: remove the discard_zeroes_data flag
From: hch @ 2017-05-10 14:06 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: hch@lst.de, Bart Van Assche, agk@redhat.com,
lars.ellenberg@linbit.com, snitzer@redhat.com,
martin.petersen@oracle.com, philipp.reisner@linbit.com,
axboe@kernel.dk, shli@kernel.org, linux-scsi@vger.kernel.org,
dm-devel@redhat.com, drbd-dev@lists.linbit.com,
linux-block@vger.kernel.org, target-devel@vger.kernel.org,
linux-raid@vger.kernel.org
In-Reply-To: <1494312374.16894.36.camel@haakon3.risingtidesystems.com>
On Mon, May 08, 2017 at 11:46:14PM -0700, Nicholas A. Bellinger wrote:
> That said, simply propagating up q->limits.max_write_zeroes_sectors as
> dev_attrib->unmap_zeroes_data following existing code still looks like
> the right thing to do.
It is not. Martin has decoupled write same/zeroes support from discard
support. Any device will claim to support it initially, and we'll
only clear the flag if a Write Same command fails.
So even if LBPRZ is not set you can trivially get into a situation
where discard is supported through UNMAP, and you'll incorrectly
set LBPRZ and will cause data corruption.
^ permalink raw reply
* Re: [PATCH] IMSM: Correct --examine output for 4k disks
From: Jes Sorensen @ 2017-05-10 15:18 UTC (permalink / raw)
To: Mariusz Dabrowski, linux-raid; +Cc: Maksymilian Kunt
In-Reply-To: <5e8e5353-e42d-0ea0-1928-7d4608a884b8@intel.com>
On 05/10/2017 04:43 AM, Mariusz Dabrowski wrote:
> On 05/09/2017 06:04 PM, Jes Sorensen wrote:
> > On 05/09/2017 08:03 AM, Mariusz Dabrowski wrote:
> >> From: Maksymilian Kunt <maksymilian.kunt@intel.com>
> >>
> >> "Array Size" and "Per Dev Size" are incorrect for disks with sector
> size
> >> different than 512B.
> >>
> >> Calculate "Array Size" and "Per Dev Size" based on sector size.
> Additionally
> >> print "Sector Size".
> >>
> >> Signed-off-by: Maksymilian Kunt <maksymilian.kunt@intel.com>
> >> Signed-off-by: Mariusz Dabrowski <mariusz.dabrowski@intel.com>
> >> ---
> >> super-intel.c | 7 +++++--
> >> 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > I am a little wary of this change as it changes the order of the
> output. Does
> > anyone have tools parsing this information which could break from this?
> >
> > Jes
> >
>
> Hi Jes,
>
> some time ago we have added "RWH Policy" field to --examine output and
> we haven't heard any complaints about that change.
> Also it is better to parse output from --export option which is
> unchanged in this patch.
Hi Mariusz,
That is correct, however the policy stuff was added to the end of the
output, it didn't change the existing part. I am a little mixed on this
one, but I do agree --export should be the recommended use case for scripts.
Cheers,
Jes
^ permalink raw reply
* [PATCH] md:raid1/10: avoid unnecessary locking
From: shli @ 2017-05-10 15:52 UTC (permalink / raw)
To: linux-raid; +Cc: Shaohua Li, NeilBrown
From: Shaohua Li <shli@fb.com>
If we add bios to block plugging list, locking is unnecessry, since the block
unplug is guaranteed not to run at that time.
Cc: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
---
drivers/md/raid1.c | 7 +++----
drivers/md/raid10.c | 7 +++----
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 7c1f73398800..a17ed6218d51 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -1529,17 +1529,16 @@ static void raid1_write_request(struct mddev *mddev, struct bio *bio,
plug = container_of(cb, struct raid1_plug_cb, cb);
else
plug = NULL;
- spin_lock_irqsave(&conf->device_lock, flags);
if (plug) {
bio_list_add(&plug->pending, mbio);
plug->pending_cnt++;
} else {
+ spin_lock_irqsave(&conf->device_lock, flags);
bio_list_add(&conf->pending_bio_list, mbio);
conf->pending_count++;
- }
- spin_unlock_irqrestore(&conf->device_lock, flags);
- if (!plug)
+ spin_unlock_irqrestore(&conf->device_lock, flags);
md_wakeup_thread(mddev->thread);
+ }
}
r1_bio_write_done(r1_bio);
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index 6b86a0032cf8..4343d7ff9916 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -1282,17 +1282,16 @@ static void raid10_write_one_disk(struct mddev *mddev, struct r10bio *r10_bio,
plug = container_of(cb, struct raid10_plug_cb, cb);
else
plug = NULL;
- spin_lock_irqsave(&conf->device_lock, flags);
if (plug) {
bio_list_add(&plug->pending, mbio);
plug->pending_cnt++;
} else {
+ spin_lock_irqsave(&conf->device_lock, flags);
bio_list_add(&conf->pending_bio_list, mbio);
conf->pending_count++;
- }
- spin_unlock_irqrestore(&conf->device_lock, flags);
- if (!plug)
+ spin_unlock_irqrestore(&conf->device_lock, flags);
md_wakeup_thread(mddev->thread);
+ }
}
static void raid10_write_request(struct mddev *mddev, struct bio *bio,
--
2.11.0
^ permalink raw reply related
* Re: MD device tinning documentation
From: Shaohua Li @ 2017-05-10 16:00 UTC (permalink / raw)
To: Vladimir Fedorkov; +Cc: linux-raid
In-Reply-To: <CA+DJSLwbsUhhK_T+K6YOBX_BLdgRn=qZjz3LUAK92A0_9sL0FQ@mail.gmail.com>
On Mon, May 08, 2017 at 01:22:53PM +0300, Vladimir Fedorkov wrote:
> Hello there!
>
> I'm running benchmarks and it looks like that md device is only
> utilizing single core which it limiting it's performance on concurrent
> (4+ threads) writes with 8 SSD drives in software RAID10
>
> Kernel: Linux host 4.10.12-1.el7.elrepo.x86_64 #1 SMP Fri Apr 21
> 09:58:15 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux
>
> Exact numbers are here: http://astellar.com/images/sysbench_rnd_writes.png
>
> Could you please let me know if there is multi-threaded support on MD
> devices in 4.x kernels and point me to the documentation (preferred)
> or source code which describes tunable parts of /dev/mdXX devices.
There is no knob for tunning. At most time, raid10 directly sends IO to
underlayer disks directly from upperlayer thread, so it's multi-threaded. The
problem is we have some locking issues in the barrier side. Coly improved the
raid1 scalability with a new barrier implementation (fd76863e37fe RAID1: a new
I/O barrier implementation to remove resync window), but raid10 is left behind.
Thanks,
Shaohua
^ permalink raw reply
* Re: [PATCH] md/md0: optimize raid0 discard handling
From: Shaohua Li @ 2017-05-10 16:09 UTC (permalink / raw)
To: NeilBrown; +Cc: Shaohua Li, linux-raid, Kernel-team, Coly Li
In-Reply-To: <87r2zyn8op.fsf@notabene.neil.brown.name>
On Tue, May 09, 2017 at 11:03:02AM +1000, Neil Brown wrote:
> On Sun, May 07 2017, Shaohua Li wrote:
>
> > There are complaints that raid0 discard handling is slow. Currently we
> > divide discard request into chunks and dispatch to underlayer disks. The
> > block layer will do merge to form big requests. This causes a lot of
> > request split/merge and uses significant CPU time.
> >
> > A simple idea is to calculate the range for each raid disk for an IO
> > request and send a discard request to raid disks, which will avoid the
> > split/merge completely. Previously Coly tried the approach, but the
> > implementation was too complex because of raid0 zones. This patch always
> > split bio in zone boundary and handle bio within one zone. It simplifies
> > the implementation a lot.
> >
> > Cc: NeilBrown <neilb@suse.com>
> > Cc: Coly Li <colyli@suse.de>
> > Signed-off-by: Shaohua Li <shli@fb.com>
>
> Reviewed-by: NeilBrown <neilb@suse.com>
>
> I'm a little bit bothered by the use for __blkdev_issue_discard() which
> uses bio_alloc(), which allocates from fs_bio_set. This code isn't in a
> filesystem, so it feels wrong.
>
> fs_bio_set has 4 entries. If 4 different threads call
> __blkdev_issue_discard() on a raid0 device, they could get allocated all
> of the entries from the pool. Then when raid0 calls
> __blkdev_issue_discard(), the pool is empty.
>
> I don't think this is actually a problem as discard (presumably) doesn't
> happen on the write-out-for-memory-reclaim path, so the bio_alloc() will
> eventually be able to get memory from kmalloc() rather than from the
> pool.
>
> Maybe next_bio() should use the bio_split pool from
> bio->bi_bdev->queue. But it probably doesn't really matter.
Indead this part isn't comfortable. I'd suppose discard is only called in
transaction thread of fs, so only one thread is calling into discard. Probably
not a big deal.
Thanks,
Shaohua
^ permalink raw reply
* Re: Fault tolerance with badblocks
From: Edward Kuns @ 2017-05-10 16:44 UTC (permalink / raw)
To: Chris Murphy; +Cc: Wols Lists, Linux-RAID
In-Reply-To: <CAJCQCtR0y-g+8dKC2-fykmFnOPKMA5YQs-Hku67c79SMECQrEg@mail.gmail.com>
On Tue, May 9, 2017 at 10:53 PM, Chris Murphy <lists@colorremedies.com> wrote:
> Scrubs don't happen by default.
From the perspective of Linux Raid authors, that is true. However,
the version of Fedora I have installed on my server at home does
weekly scrubs by default. This is arguably a good thing, considering
that many people installing this OS will not proactively research the
technologies in use holding their server together and won't know that
there are certain maintenance activities that are essential if you
care about your data.
I'm not getting involved in the bigger discussion. My opinion is too
uninformed to say anything there. I just wanted to point out that
*from the viewpoint of some users*, scrubs *will* happen by default.
That is all.
Eddie
^ permalink raw reply
* Re: [PATCH v4 2/2] md/r5cache: gracefully handle journal device errors for writeback mode
From: Shaohua Li @ 2017-05-10 17:01 UTC (permalink / raw)
To: Song Liu
Cc: linux-raid, shli, neilb, kernel-team, dan.j.williams, hch,
jes.sorensen
In-Reply-To: <20170509003925.3480693-2-songliubraving@fb.com>
On Mon, May 08, 2017 at 05:39:25PM -0700, Song Liu wrote:
> For the raid456 with writeback cache, when journal device failed during
> normal operation, it is still possible to persist all data, as all
> pending data is still in stripe cache. However, it is necessary to handle
> journal failure gracefully.
>
> During journal failures, this patch makes the follow changes to land data
> in cache to raid disks gracefully:
>
> 1. In handle_stripe(), allow stripes with data in journal (s.injournal > 0)
> to make progress;
> 2. In delay_towrite(), only process data in the cache (skip dev->towrite);
> 3. In __get_priority_stripe(), set try_loprio to true, so no stripe stuck
> in loprio_list
Applied the first patch. For this patch, I don't have a clear picture about
what you are trying to do. Please describe the steps we are doing to do after
journal failure.
> Signed-off-by: Song Liu <songliubraving@fb.com>
> ---
> drivers/md/raid5-cache.c | 13 ++++++++++---
> drivers/md/raid5-log.h | 3 ++-
> drivers/md/raid5.c | 29 +++++++++++++++++++++++------
> 3 files changed, 35 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
> index dc1dba6..e6032f6 100644
> --- a/drivers/md/raid5-cache.c
> +++ b/drivers/md/raid5-cache.c
> @@ -24,6 +24,7 @@
> #include "md.h"
> #include "raid5.h"
> #include "bitmap.h"
> +#include "raid5-log.h"
>
> /*
> * metadata/data stored in disk with 4k size unit (a block) regardless
> @@ -679,6 +680,7 @@ static void r5c_disable_writeback_async(struct work_struct *work)
> return;
> pr_info("md/raid:%s: Disabling writeback cache for degraded array.\n",
> mdname(mddev));
> + md_update_sb(mddev, 1);
Why this? And md_update_sb must be called within mddev->reconfig_mutex locked.
> mddev_suspend(mddev);
> log->r5c_journal_mode = R5C_JOURNAL_MODE_WRITE_THROUGH;
> mddev_resume(mddev);
> @@ -1557,6 +1559,8 @@ void r5l_wake_reclaim(struct r5l_log *log, sector_t space)
> void r5l_quiesce(struct r5l_log *log, int state)
> {
> struct mddev *mddev;
> + struct r5conf *conf;
> +
> if (!log || state == 2)
> return;
> if (state == 0)
> @@ -1564,10 +1568,12 @@ void r5l_quiesce(struct r5l_log *log, int state)
> else if (state == 1) {
> /* make sure r5l_write_super_and_discard_space exits */
> mddev = log->rdev->mddev;
> + conf = mddev->private;
> wake_up(&mddev->sb_wait);
> kthread_park(log->reclaim_thread->tsk);
> r5l_wake_reclaim(log, MaxSector);
> - r5l_do_reclaim(log);
> + if (!r5l_log_disk_error(conf))
> + r5l_do_reclaim(log);
I think r5c_disable_writeback_async() will call into this, so we flush all
stripe cache out to raid disks, why skip the reclaim?
Thanks,
Shaohua
^ permalink raw reply
* Re: RFC - Raid error detection and auto-recovery (was Fault tolerance with badblocks)
From: Piergiorgio Sartor @ 2017-05-10 17:07 UTC (permalink / raw)
To: Wols Lists; +Cc: linux-raid, Nix
In-Reply-To: <591314F4.2010702@youngman.org.uk>
On Wed, May 10, 2017 at 02:26:12PM +0100, Wols Lists wrote:
> This discussion seems to have become a bit heated, but I think we have
> the following:
>
> FACT: linux md raid can do error detection but doesn't. Why not? It
> seems people are worried about the performance hit.
>
> FACT: linux md raid can do automatic error correction but doesn't. Why
> not? It seems people are more worried about the problems it could cause
> than the problems it would fix.
>
> OBSERVATION: The kernel guys seem to get fixated on kernel performance
> and miss the bigger picture. At the end of the day, the most important
> thing on the computer is the USER'S DATA. And if we can't protect that,
> they'll throw the computer in the bin. Or replace linux with Windows. Or
> something like that. And when there's a problem, it all too often comes
> over that the kernel guys CAN fix it but WON'T. The ext2/3/4 transition
> is a case in point. The current frustration where the kernel guys say
> "user data is the application's problem" but the postgresql guys are
> saying "how can we guarantee integrity when you won't give us the tools
> we need to guarantee our data is safe".
>
> This situation smacks of the same arrogance, sorry. "We can save your
> data but we won't".
>
> FURTHER FACTUAL TIDBITS:
>
> The usual response seems to be to push the problem somewhere else. For
> example "The user should keep backups". BUT HOW? I've investigated!
>
> Let's say I buy a spare drive for my backup. But I installed raid to
> avoid being at the mercy of a single drive. Now I am again because my
> backup is a single drive! BIG FAIL.
>
> Okay, I'll buy two drives, and have a backup raid. But what if my backup
> raid is reporting a mismatch count too? Now I have TWO copies where I
> can't vouch for their integrity. Double the trouble. BIG FAIL.
>
> Tape is cheap, you say? No bl***ding way!!! I've just done a quick
> investigation, and for the price of a tape drive I could probably turn
> my 2x3TB raid-1 into a 3x3TB raid-5, AND buy sufficient disks to
> implement a raid-based grandfather/father/son backup procedure, and
> STILL have some change left over. (I am using cheapie desktop drives,
> but I could probably afford cheap NAS drives with that money.)
>
> PROPOSAL: Enable integrity checking.
>
> We need to create something like /sys/md/array/verify_data_on_read. If
> that's set to true and we can check integrity (ie not raid-0), rather
> than reading just the data disks, we read the entire stripe, check the
> mirror or parity, and then decide what to do. If we can return
> error-corrected data obviously we do. I think we should return an error
> if we can't, no?
>
> We can't set this by default. The *potential* performance hit is too
> great. But now the sysadmin can choose between performance or integrity,
> rather than the present state where he has no choice. And in reality, I
> don't think a system like mine would even notice! Low read/write
> activity, and masses of spare ram. Chances are most of my disk activity
> is cached and doesn't go anywhere near the raid code.
>
> The kernel code size impact is minimal, I suspect. All the code required
> is probably there, it just needs a little "re-purposing".
>
> PROPOSAL: Enable automatic correction
>
> Likewise create /sys/md/array/correct_data_on_read. This won't work if
> verify_data_on_read is not set, and likewise it will not be set by
> default. IFF we need to reconstruct the data from a 3-or-more raid-1
> mirror or a raid-6, it will rewrite the corrected stripe.
>
> RATIONALE:
>
> NEVER THROW AWAY USER DATA IF YOU CAN RECONSTRUCT IT !!!
>
> This gives control to the sysadmin. At the end of the day, it should be
> *his* call, not the devs', as to whether verify-on-read is worth the
> performance hit. (Successful reconstructions should be logged ...)
>
> Likewise, while correct_data_on_read could mess up the array if the
> error isn't actually on the drive, that should be the sysadmin's call,
> not the devs'. And because we only rewrite if we think we have
> successfully recreated the data, the chances of it messing up are
> actually quite small. Because verify_data_on_read is set, that addresses
> Neil's concern of changing the data underneath an app - the app has been
> given the corrected data so we write the corrected data back to disk.
>
> NOTES:
>
> >From Peter Anvin's paper it seems that the chance of wrongly identifying
> a single-disk error is low. And it's even lower if we look for the clues
> he mentions. Because we only correct those errors we are sure we've
> correctly identified, other sources of corruption shouldn't get fed back
> to the disk.
>
> This makes an error-correcting scrub easy :-) Run as an overnight script...
> cat 1 > /sys/md/root/verify_data_on_read
> cat 1 > /sys/md/root/correct_data_on_read
> tar -c / > /dev/null
> cat 0 > /sys/md/root/correct_data_on_read
> cat 0 > /sys/md/root/verify_data_on_read
>
>
> Coders and code welcome ... :-)
I just would like to stress the fact that
there is user-space code (raid6check) which
perform check, possibily repair, on RAID6.
bye,
>
> Cheers,
> Wol
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
piergiorgio
^ permalink raw reply
* Re: Fault tolerance with badblocks
From: Chris Murphy @ 2017-05-10 17:18 UTC (permalink / raw)
To: Wols Lists; +Cc: Chris Murphy, Linux-RAID
In-Reply-To: <59129BC1.2090005@youngman.org.uk>
On Tue, May 9, 2017 at 10:49 PM, Wols Lists <antlists@youngman.org.uk> wrote:
> On 10/05/17 04:53, Chris Murphy wrote:
>> On Tue, May 9, 2017 at 1:44 PM, Wols Lists <antlists@youngman.org.uk> wrote:
>>
>>>> This is totally non-trivial, especially because it says raid6 cannot
>>>> detect or correct more than one corruption, and ensuring that
>>>> additional corruption isn't introduced in the rare case is even more
>>>> non-trivial.
>>>
>>> And can I point out that that is just one person's opinion?
>>
>> Right off the bat you ask a stupid question that contains the answer
>> to your own stupid question. This is condescending and annoying, and
>> it invites treating you with suspicious as a troll. But then you make
>> it worse by saying it again:
>>
> Sorry. But I thought we were talking about *Neil's* paper. My bad for
> missing it.
Doesn't matter. Your standard is mere opinions are ignorable, and
therefore by your own standard you can be ignored for posing mere
opinions yourself. You set your own trap but you clearly want to hold
a double standard: your opinions are valid and should be listened to,
and others' opinions are merely opinion and can be easily discarded.
>>> A
>>> well-informed, respected person true, but it's still just opinion.
>>
>> Except it is not just an opinion, it's a fact by any objective reader
>> who isn't even a programmer, let alone if you know something about
>> math and/or programming. Let's break down how totally stupid your
>> position is.
>>
>
> <snip ad hominems :-) >
It is not an ad hominem attack to evaluate your lack of logic. An ad
hominem attack is one on the person rather than their arguments. I
haven't attacked you, I've attacked your arguing style and the deep
ignorance that style conveys. And you shouldn't like it, but you have
only yourself to blame, you didn't exactly bother to do any list
archive research before demanding everyone's foolish for having
withheld this feature from you personally. It almost immediately
became noise.
>>> At the end of the day, md should never corrupt data by default. Which is
>>> what it sounds like is happening at the moment, if it's assuming the
>>> data sectors are correct and the parity is wrong. If one parity appears
>>> correct then by all means rewrite the second ...
>>
>> This is an obtuse and frankly malicious characterization. Scrubs don't
>> happen by default. And scrub repair's assuming data strips are correct
>> is well documented. If you don't like this assumption, don't use scrub
>> repair. You can't say corruption happens by default unless you admit
>> that there's URE's on a drive by default - of course that's absurd and
>> makes no sense.
>>
> Documenting bad behaviour doesn't turn it into good behaviour, though ...
It is a common loophole to describe the chosen behavior when good
behavior is difficult or infeasible. It happens all the time.
Complaining here isn't going to change this.
>>>
>>> But the current setup, where it's currently quite happy to assume a
>>> single-drive error and rewrite it if it's a parity drive, but it won't
>>> assume a single-drive error and and rewrite it if it's a data drive,
>>> just seems totally wrong. Worse, in the latter case, it seems it
>>> actively prevents fixing the problem by updating the parity and
>>> (probably) corrupting the data.
>>
>> The data is already corrupted by definition. No additional damage to
>> data is done. What does happen is good P and Q are replaced by bad P
>> and Q which matches the already bad data.
>
> Except, in my world, replacing good P & Q by bad P & Q *IS* doing
> additional damage!
Arguing about it doesn't make it true. The primary data is corrupt and
in normal operation P & Q are not checked, so it will always silently
return corrupt data in normal operation, and if there is a failure
that does not exactly coincide with the corruption, the corruption
that is read in the ensuing reconstruction will corrupt the
reconstruction even though P & Q are good. So what you want to fix is
a lot of buck for almost no gain.
>We can identify and fix the bad data. So why don't
> we? Throwing away good P & Q prevents us from doing that, and means we
> can no longer recover the good data!
There is no possible way to know that P & Q are both good. That
requires assumption. So you've arbitrarily traded an assumption you
don't like for one that you do like, but have no evidence for in
either case.
There are better ways to solve this problem. md and LVM raid are
really about solving one, or two particular problemswhich is not data
integrity, it is data availability and recovery via reconstruction
rather than from backups being restored.
Better is defined by the use case at hand. Some use cases will want
this solved at the file system level, which points to ZFS or Btrfs -
the very problem you're talking about is one of those problems that
led to the design of both of those file systems. Other use cases can
have it solved at an application level. And still others will solve it
with a cluster file system, like glusterfs does with per file
checksums and replication.
>> And nevertheless you have the very real problem that drives lie about
>> having committed data to stable media. And they reorder writes,
>> breaking the write order assumptions of things. And we have RMW
>> happening on live arrays. And that means you have a real likelihood
>> that you cannot absolutely determine with the available information
>> why P and Q don't agree with the data, you're still making probability
>> assumptions and if that assumption is wrong any correction will
>> introduce more corruption.
>>
>> The only unambiguous way to do this has already been done and it's ZFS
>> and Btrfs. And a big part of why they can do what they do is because
>> they are copy on write. IIf you need to solve the problem of ambiguous
>> data strip integrity in relation to P and Q, then use ZFS. It's
>> production ready. If you are prepared to help test and improve things,
>> then you can look into the Btrfs implementation.
>
> So how come btrfs and ZFS can handle this, and md can't?
All data and metadata blocks are checksummed, and they're always
verified during normal operation for every read. The data checksums
are themselves checksummed. Even if a drive does not report an error,
error can be detected, and trigger reconstruction if redundant
metadata or data is available.
md does not checksum anything but its own metadata which is just the
superblock, there isn't much of anything else to it. There's no
checksums for data strips, parity strips, there's no timestamp for any
of the writes, there's a distinct lack of information to be able to do
an autopsy after the fact without any assumptions.
> Can't md use
> the same techniques. (Seriously, I don't know the answer. But, like Nix,
> when I feel I'm being fed the answer "we're not going to give you the
> choice because we know better than you", I get cheesed off. If I get the
> answer "we're snowed under, do it yourself" then that is normal and
> acceptable.)
No they operate on completely different architecture and assumptions.
You really should search the archives, all of these things you're
wanting to discuss now have already been discussed and argued and
nothing has changed.
>>
>> Otherwise I'm sure md and LVM folks have a feature list that
>> represents a few years of work as it is without yet another pile on.
>>
>>>
>>> Report the error, give the user the tools to fix it, and LET THEM sort
>>> it out. Just like we do when we run fsck on a filesystem.
>>
>> They're not at all comparable. One is a file system, the other a raid
>> implementation, they have nothing in common.
>>
>>
> And what are file systems and raid implementations? They are both data
> store abstractions. They have everything in common.
They have almost nothing in common. File systems store files. RAIDs do
not know anything at all about files. RAID has a superblock, and a
couple of optional logs for very specific purposes, there are no
trees. RAID works by logical assumptions where things are located, it
doesn't do lookups using metadata to find your data, it's all
determined by geometry, totally unlike a file system.
>
> Oh and by the way, now I've realised my mistake, I've taken a look at
> the paper you mention. In particular, section 4. Yes it does say you
> can't detect and correct multi-disk errors - but that's not what we're
> asking for!
>
> By implication, it seems to be saying LOUD AND CLEAR that you CAN detect
> and correct a single-disk error. So why the blankety-blank won't md let
> you do that!
It's one particular kind of error and there isn't enough on disk
metadata to differentiate this particular kind of error after the
fact. You're looking at this problem in total isolation to all other
problems. And you're not familiar with the lack of information
available in the corpse.
Neil's version of this explanation:
"Similarly a RAID6 with inconsistent P and Q could well not be able to
identify a single block which is "wrong" and even if it could there is
a small possibility that the identified block isn't wrong, but the
other blocks are all inconsistent in such a way as to accidentally
point to it. The probability of this is rather small, but it is
non-zero."
The autofix in such a case could cause more damage.
>
> Neil's point seems to be that it's a bad idea to do it automatically. I
> get his logic. But to then actively prevent you doing it manually - this
> is the paternalistic attitude that gets my goat.
You have no example code. You've basically come on the list, without
any prior research, and said "GIMME!"
*shrug*
>
> Anyways, I've been thinking about this, and I've got a proposal (RFC?).
> I haven't got time right now - I'm supposed to be at work - but I'll
> write it up this evening. If the response is "we're snowed under - it
> sounds a good idea but do it yourself", then so be it. But if the
> response is "we don't want the sysadmin to have the choice", then expect
> more flak from people like Nix and me.
1. The default response without having to say it is "we're snowed
under, show us a proof of concept first".
2. You have no imagination by having assumed this has never come up
before, instead thinking you're the first to have this feature in mind
3. You took the ensuing resistance personally.
You have an idea, the burden is on you to demonstrate a need, provide
code examples, and ask the right questions like "would the maintainers
accept some changes for error reporting for scrub checks?" At the very
least what you suggest indicates error reporting enhancements so why
not ask about those parameters?
Instead, from the outset you treated this resistance as if other
people are your grumpy daddy and they're just being mean to you.
That's why you got the reception you did. Mischaracterizing other
people as being paternalistic isn't going to help get a different
perception. (I was thinking of Commander Sela, referring to Toral,
when she said "Silence the child or send him away!")
My proposal for your proposal is a patch that implements equation 27
from HPA's paper, and enhances error reporting per its descriptive
outcomes.
md: error: mismatch, P corruption, array logical <LBA>
md: error: mismatch, Q corruption, array logical <LBA>
md: error: mismatch, data corruption suspected, array logical <LBA>
That's subject to wording and formatting discussion, I have not looked
at existing formatting, but you need to ask if approximately this
would be accepted.
However, the main point is that you need to find out what the
computational cost is for this scrub enhancement is. If it takes 5
times longer, even you will laugh and say it's not worth it. Stop
asking "why isn't this already implemented! do it now! now! now! now!"
Instead ask "what is the ballpark maximum performance impact to scrub
that would be accepted? And if that maximum is busted would
maintainers consider a new value "check2" to write to echo check >
/sys/block/mdX/md/sync_action?"
Once you have better error reporting, a user space tool could use the
array metadata, and the error reporting LBA to lookup that stripe and
reconstruct just that stripe with the assumption that P & Q are
correct and hopefully fix your data. Or whatever other assumptions you
want to try and make to attempt different recoveries. That user space
tool could also backup the existing stripe so the fixes are all
reversible.
--
Chris Murphy
^ permalink raw reply
* Re: RAID creation resync behaviors
From: Shaohua Li @ 2017-05-10 17:30 UTC (permalink / raw)
To: Jes Sorensen; +Cc: Martin K. Petersen, NeilBrown, linux-raid, neilb
In-Reply-To: <f73c7524-5d35-6104-11b1-2c658b43c68d@gmail.com>
On Tue, May 09, 2017 at 05:22:57PM -0400, Jes Sorensen wrote:
> On 05/09/2017 05:16 PM, Martin K. Petersen wrote:
> >
> > Jes,
> >
> > > This is fine within the kernel, however it is not overly useful for
> > > mdadm to determine which strategy to apply when syncing devices.
> >
> > BLKZEROOUT
> >
>
> Trying to read the code, as this ioctl doesn't seem to be documented
> anywhere I can find.... it looks like this ioctl zeroes out a device.
>
> It doesn't help me obtain the information I need to make a decision in mdadm
> as whether to overwrite all or compare+write when resyncing a RAID array.
The best way I can think is if we find the disks are SSD, trim the disks, and
read some random places. If all return 0, the guess is the SSD returns 0 after
trim, so do compare-write resync otherwise overwrite. Surely this needs extra
mdadm option to enable. We can only reliably detect a SSD, others lie.
Thanks,
Shaohua
^ permalink raw reply
* cleanup UUID types
From: Christoph Hellwig @ 2017-05-10 18:01 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells, Mimi Zohar,
Steven Whitehouse
Hi all,
this series, which is a combined effort from Amir, Andy and me introduces
new uuid_t and guid_t type names that are less confusing than the existing
types, adds new helpers for them and starts switching the fs code over to
it. Andy has additional patches on top to convert many of the users
that use char arrays for UUIDs and GUIDs to these (or rather a predecessor
for now until updated).
^ permalink raw reply
* [PATCH 01/16] xfs: use uuid_copy() helper to abstract uuid_t
From: Christoph Hellwig @ 2017-05-10 18:01 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells, Mimi Zohar,
Steven Whitehouse
In-Reply-To: <20170510180214.16852-1-hch-jcswGhMUV9g@public.gmane.org>
From: Amir Goldstein <amir73il-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
uuid_t definition is about to change.
Signed-off-by: Amir Goldstein <amir73il-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
fs/xfs/xfs_inode_item.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/fs/xfs/xfs_inode_item.c b/fs/xfs/xfs_inode_item.c
index 08cb7d1a4a3a..013cc78d7daf 100644
--- a/fs/xfs/xfs_inode_item.c
+++ b/fs/xfs/xfs_inode_item.c
@@ -834,9 +834,7 @@ xfs_inode_item_format_convert(
in_f->ilf_dsize = in_f32->ilf_dsize;
in_f->ilf_ino = in_f32->ilf_ino;
/* copy biggest field of ilf_u */
- memcpy(in_f->ilf_u.ilfu_uuid.__u_bits,
- in_f32->ilf_u.ilfu_uuid.__u_bits,
- sizeof(uuid_t));
+ uuid_copy(&in_f->ilf_u.ilfu_uuid, &in_f32->ilf_u.ilfu_uuid);
in_f->ilf_blkno = in_f32->ilf_blkno;
in_f->ilf_len = in_f32->ilf_len;
in_f->ilf_boffset = in_f32->ilf_boffset;
@@ -851,9 +849,7 @@ xfs_inode_item_format_convert(
in_f->ilf_dsize = in_f64->ilf_dsize;
in_f->ilf_ino = in_f64->ilf_ino;
/* copy biggest field of ilf_u */
- memcpy(in_f->ilf_u.ilfu_uuid.__u_bits,
- in_f64->ilf_u.ilfu_uuid.__u_bits,
- sizeof(uuid_t));
+ uuid_copy(&in_f->ilf_u.ilfu_uuid, &in_f64->ilf_u.ilfu_uuid);
in_f->ilf_blkno = in_f64->ilf_blkno;
in_f->ilf_len = in_f64->ilf_len;
in_f->ilf_boffset = in_f64->ilf_boffset;
--
2.11.0
^ permalink raw reply related
* [PATCH 02/16] xfs: use uuid_be to implement the uuid_t type
From: Christoph Hellwig @ 2017-05-10 18:02 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells, Mimi Zohar,
Steven Whitehouse
In-Reply-To: <20170510180214.16852-1-hch-jcswGhMUV9g@public.gmane.org>
Use the generic Linux definition to implement our UUID type, this will
allow using more generic infrastructure in the future.
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
fs/xfs/uuid.h | 4 ----
fs/xfs/xfs_linux.h | 3 +++
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/fs/xfs/uuid.h b/fs/xfs/uuid.h
index 104db0f3bed6..4f1441ba4fa5 100644
--- a/fs/xfs/uuid.h
+++ b/fs/xfs/uuid.h
@@ -18,10 +18,6 @@
#ifndef __XFS_SUPPORT_UUID_H__
#define __XFS_SUPPORT_UUID_H__
-typedef struct {
- unsigned char __u_bits[16];
-} uuid_t;
-
extern int uuid_is_nil(uuid_t *uuid);
extern int uuid_equal(uuid_t *uuid1, uuid_t *uuid2);
extern void uuid_getnodeuniq(uuid_t *uuid, int fsid [2]);
diff --git a/fs/xfs/xfs_linux.h b/fs/xfs/xfs_linux.h
index 044fb0e15390..89ee5ec66837 100644
--- a/fs/xfs/xfs_linux.h
+++ b/fs/xfs/xfs_linux.h
@@ -19,6 +19,7 @@
#define __XFS_LINUX__
#include <linux/types.h>
+#include <linux/uuid.h>
/*
* Kernel specific type declarations for XFS
@@ -38,6 +39,8 @@ typedef __s64 xfs_daddr_t; /* <disk address> type */
typedef __u32 xfs_dev_t;
typedef __u32 xfs_nlink_t;
+typedef uuid_be uuid_t;
+
#include "xfs_types.h"
#include "kmem.h"
--
2.11.0
^ permalink raw reply related
* [PATCH 03/16] uuid: rename uuid types
From: Christoph Hellwig @ 2017-05-10 18:02 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells, Mimi Zohar,
Steven Whitehouse
In-Reply-To: <20170510180214.16852-1-hch-jcswGhMUV9g@public.gmane.org>
Our "little endian" UUID really is a Wintel GUID, so rename it and its
helpers such (guid_t). The big endian UUID is the only true one, so
give it the name uuid_t. The uuid_le and uuid_be names are retained for,
but will hopefully go away soon.
Also remove the existing typedef in XFS that's now been superceeded by
the generic type name.
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
[andy: also updated the UUID_LE/UUID_BE macros including fallout]
Signed-off-by: Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
fs/jfs/jfs_logmgr.h | 4 ++--
fs/xfs/xfs_linux.h | 2 --
include/linux/efi.h | 3 +--
include/linux/uuid.h | 28 ++++++++++++++++++----------
include/uapi/linux/uuid.h | 27 +++++++++++++++------------
lib/test_uuid.c | 12 ++++++------
lib/uuid.c | 28 ++++++++++++++--------------
lib/vsprintf.c | 4 ++--
8 files changed, 58 insertions(+), 50 deletions(-)
diff --git a/fs/jfs/jfs_logmgr.h b/fs/jfs/jfs_logmgr.h
index e38c21598850..0b9efddeb9f5 100644
--- a/fs/jfs/jfs_logmgr.h
+++ b/fs/jfs/jfs_logmgr.h
@@ -19,6 +19,8 @@
#ifndef _H_JFS_LOGMGR
#define _H_JFS_LOGMGR
+#include <linux/uuid.h>
+
#include "jfs_filsys.h"
#include "jfs_lock.h"
@@ -80,8 +82,6 @@ struct logsuper {
} active[MAX_ACTIVE]; /* 2048: active file systems list */
};
-#define NULL_UUID "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
-
/* log flag: commit option (see jfs_filsys.h) */
/* log state */
diff --git a/fs/xfs/xfs_linux.h b/fs/xfs/xfs_linux.h
index 89ee5ec66837..2c33d915e550 100644
--- a/fs/xfs/xfs_linux.h
+++ b/fs/xfs/xfs_linux.h
@@ -39,8 +39,6 @@ typedef __s64 xfs_daddr_t; /* <disk address> type */
typedef __u32 xfs_dev_t;
typedef __u32 xfs_nlink_t;
-typedef uuid_be uuid_t;
-
#include "xfs_types.h"
#include "kmem.h"
diff --git a/include/linux/efi.h b/include/linux/efi.h
index ec36f42a2add..cbd4d00e62c5 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -50,7 +50,7 @@ typedef void *efi_handle_t;
typedef uuid_le efi_guid_t;
#define EFI_GUID(a,b,c,d0,d1,d2,d3,d4,d5,d6,d7) \
- UUID_LE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7)
+ GUID(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7)
/*
* Generic EFI table header
@@ -584,7 +584,6 @@ void efi_native_runtime_setup(void);
* Note that the 'extra space' separates the values at the same place
* where the UEFI SPEC breaks the line.
*/
-#define NULL_GUID EFI_GUID(0x00000000, 0x0000, 0x0000, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00)
#define MPS_TABLE_GUID EFI_GUID(0xeb9d2d2f, 0x2d88, 0x11d3, 0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
#define ACPI_TABLE_GUID EFI_GUID(0xeb9d2d30, 0x2d88, 0x11d3, 0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
#define ACPI_20_TABLE_GUID EFI_GUID(0x8868e871, 0xe4f1, 0x11d3, 0xbc, 0x22, 0x00, 0x80, 0xc7, 0x3c, 0x88, 0x81)
diff --git a/include/linux/uuid.h b/include/linux/uuid.h
index 4dff73a89758..af669f317780 100644
--- a/include/linux/uuid.h
+++ b/include/linux/uuid.h
@@ -48,27 +48,35 @@ struct uuid_v1 {
*/
#define UUID_STRING_LEN 36
-static inline int uuid_le_cmp(const uuid_le u1, const uuid_le u2)
+static inline int guid_cmp(const guid_t u1, const guid_t u2)
{
- return memcmp(&u1, &u2, sizeof(uuid_le));
+ return memcmp(&u1, &u2, sizeof(guid_t));
}
-static inline int uuid_be_cmp(const uuid_be u1, const uuid_be u2)
+static inline int uuid_cmp(const uuid_t u1, const uuid_t u2)
{
- return memcmp(&u1, &u2, sizeof(uuid_be));
+ return memcmp(&u1, &u2, sizeof(uuid_t));
}
void generate_random_uuid(unsigned char uuid[16]);
-extern void uuid_le_gen(uuid_le *u);
-extern void uuid_be_gen(uuid_be *u);
+extern void guid_gen(guid_t *u);
+extern void uuid_gen(uuid_t *u);
bool __must_check uuid_is_valid(const char *uuid);
-extern const u8 uuid_le_index[16];
-extern const u8 uuid_be_index[16];
+extern const u8 guid_index[16];
+extern const u8 uuid_index[16];
-int uuid_le_to_bin(const char *uuid, uuid_le *u);
-int uuid_be_to_bin(const char *uuid, uuid_be *u);
+int guid_to_bin(const char *uuid, guid_t *u);
+int uuid_to_bin(const char *uuid, uuid_t *u);
+
+/* backwards compatibility, don't use in new code */
+#define uuid_le_cmp(u1, u2) guid_cmp(u1, u2)
+#define uuid_be_cmp(u1, u2) uuid_cmp(u1, u2)
+#define uuid_le_gen(u) guid_gen(u)
+#define uuid_be_gen(u) uuid_gen(u)
+#define uuid_le_to_bin(guid, u) guid_to_bin(guid, u)
+#define uuid_be_to_bin(uuid, u) uuid_to_bin(uuid, u)
#endif
diff --git a/include/uapi/linux/uuid.h b/include/uapi/linux/uuid.h
index 3738e5fb6a4d..1a2914d8b225 100644
--- a/include/uapi/linux/uuid.h
+++ b/include/uapi/linux/uuid.h
@@ -22,33 +22,36 @@
typedef struct {
__u8 b[16];
-} uuid_le;
+} guid_t;
typedef struct {
__u8 b[16];
-} uuid_be;
+} uuid_t;
-#define UUID_LE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) \
-((uuid_le) \
+#define GUID(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) \
+((guid_t) \
{{ (a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, ((a) >> 24) & 0xff, \
(b) & 0xff, ((b) >> 8) & 0xff, \
(c) & 0xff, ((c) >> 8) & 0xff, \
(d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7) }})
-#define UUID_BE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) \
-((uuid_be) \
+#define UUID(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) \
+((uuid_t) \
{{ ((a) >> 24) & 0xff, ((a) >> 16) & 0xff, ((a) >> 8) & 0xff, (a) & 0xff, \
((b) >> 8) & 0xff, (b) & 0xff, \
((c) >> 8) & 0xff, (c) & 0xff, \
(d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7) }})
-#define NULL_UUID_LE \
- UUID_LE(0x00000000, 0x0000, 0x0000, 0x00, 0x00, 0x00, 0x00, \
- 0x00, 0x00, 0x00, 0x00)
+#define NULL_GUID \
+ GUID(0x00000000, 0x0000, 0x0000, 0x00, 0x00, 0x00, 0x00, \
+ 0x00, 0x00, 0x00, 0x00)
-#define NULL_UUID_BE \
- UUID_BE(0x00000000, 0x0000, 0x0000, 0x00, 0x00, 0x00, 0x00, \
- 0x00, 0x00, 0x00, 0x00)
+#define NULL_UUID \
+ UUID(0x00000000, 0x0000, 0x0000, 0x00, 0x00, 0x00, 0x00, \
+ 0x00, 0x00, 0x00, 0x00)
+/* backwards compatibility, don't use in new code */
+typedef guid_t uuid_le;
+typedef uuid_t uuid_be;
#endif /* _UAPI_LINUX_UUID_H_ */
diff --git a/lib/test_uuid.c b/lib/test_uuid.c
index 547d3127a3cf..7e05c1565dcc 100644
--- a/lib/test_uuid.c
+++ b/lib/test_uuid.c
@@ -18,18 +18,18 @@ struct test_uuid_data {
static const struct test_uuid_data test_uuid_test_data[] = {
{
.uuid = "c33f4995-3701-450e-9fbf-206a2e98e576",
- .le = UUID_LE(0xc33f4995, 0x3701, 0x450e, 0x9f, 0xbf, 0x20, 0x6a, 0x2e, 0x98, 0xe5, 0x76),
- .be = UUID_BE(0xc33f4995, 0x3701, 0x450e, 0x9f, 0xbf, 0x20, 0x6a, 0x2e, 0x98, 0xe5, 0x76),
+ .le = GUID(0xc33f4995, 0x3701, 0x450e, 0x9f, 0xbf, 0x20, 0x6a, 0x2e, 0x98, 0xe5, 0x76),
+ .be = UUID(0xc33f4995, 0x3701, 0x450e, 0x9f, 0xbf, 0x20, 0x6a, 0x2e, 0x98, 0xe5, 0x76),
},
{
.uuid = "64b4371c-77c1-48f9-8221-29f054fc023b",
- .le = UUID_LE(0x64b4371c, 0x77c1, 0x48f9, 0x82, 0x21, 0x29, 0xf0, 0x54, 0xfc, 0x02, 0x3b),
- .be = UUID_BE(0x64b4371c, 0x77c1, 0x48f9, 0x82, 0x21, 0x29, 0xf0, 0x54, 0xfc, 0x02, 0x3b),
+ .le = GUID(0x64b4371c, 0x77c1, 0x48f9, 0x82, 0x21, 0x29, 0xf0, 0x54, 0xfc, 0x02, 0x3b),
+ .be = UUID(0x64b4371c, 0x77c1, 0x48f9, 0x82, 0x21, 0x29, 0xf0, 0x54, 0xfc, 0x02, 0x3b),
},
{
.uuid = "0cb4ddff-a545-4401-9d06-688af53e7f84",
- .le = UUID_LE(0x0cb4ddff, 0xa545, 0x4401, 0x9d, 0x06, 0x68, 0x8a, 0xf5, 0x3e, 0x7f, 0x84),
- .be = UUID_BE(0x0cb4ddff, 0xa545, 0x4401, 0x9d, 0x06, 0x68, 0x8a, 0xf5, 0x3e, 0x7f, 0x84),
+ .le = GUID(0x0cb4ddff, 0xa545, 0x4401, 0x9d, 0x06, 0x68, 0x8a, 0xf5, 0x3e, 0x7f, 0x84),
+ .be = UUID(0x0cb4ddff, 0xa545, 0x4401, 0x9d, 0x06, 0x68, 0x8a, 0xf5, 0x3e, 0x7f, 0x84),
},
};
diff --git a/lib/uuid.c b/lib/uuid.c
index 37687af77ff8..f80dc63f6ca8 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -21,10 +21,10 @@
#include <linux/uuid.h>
#include <linux/random.h>
-const u8 uuid_le_index[16] = {3,2,1,0,5,4,7,6,8,9,10,11,12,13,14,15};
-EXPORT_SYMBOL(uuid_le_index);
-const u8 uuid_be_index[16] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
-EXPORT_SYMBOL(uuid_be_index);
+const u8 guid_index[16] = {3,2,1,0,5,4,7,6,8,9,10,11,12,13,14,15};
+EXPORT_SYMBOL(guid_index);
+const u8 uuid_index[16] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
+EXPORT_SYMBOL(uuid_index);
/***************************************************************
* Random UUID interface
@@ -53,21 +53,21 @@ static void __uuid_gen_common(__u8 b[16])
b[8] = (b[8] & 0x3F) | 0x80;
}
-void uuid_le_gen(uuid_le *lu)
+void guid_gen(guid_t *lu)
{
__uuid_gen_common(lu->b);
/* version 4 : random generation */
lu->b[7] = (lu->b[7] & 0x0F) | 0x40;
}
-EXPORT_SYMBOL_GPL(uuid_le_gen);
+EXPORT_SYMBOL_GPL(guid_gen);
-void uuid_be_gen(uuid_be *bu)
+void uuid_gen(uuid_t *bu)
{
__uuid_gen_common(bu->b);
/* version 4 : random generation */
bu->b[6] = (bu->b[6] & 0x0F) | 0x40;
}
-EXPORT_SYMBOL_GPL(uuid_be_gen);
+EXPORT_SYMBOL_GPL(uuid_gen);
/**
* uuid_is_valid - checks if UUID string valid
@@ -115,14 +115,14 @@ static int __uuid_to_bin(const char *uuid, __u8 b[16], const u8 ei[16])
return 0;
}
-int uuid_le_to_bin(const char *uuid, uuid_le *u)
+int guid_to_bin(const char *uuid, guid_t *u)
{
- return __uuid_to_bin(uuid, u->b, uuid_le_index);
+ return __uuid_to_bin(uuid, u->b, guid_index);
}
-EXPORT_SYMBOL(uuid_le_to_bin);
+EXPORT_SYMBOL(guid_to_bin);
-int uuid_be_to_bin(const char *uuid, uuid_be *u)
+int uuid_to_bin(const char *uuid, uuid_t *u)
{
- return __uuid_to_bin(uuid, u->b, uuid_be_index);
+ return __uuid_to_bin(uuid, u->b, uuid_index);
}
-EXPORT_SYMBOL(uuid_be_to_bin);
+EXPORT_SYMBOL(uuid_to_bin);
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 2d41de3f98a1..9f37d6208e99 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1308,14 +1308,14 @@ char *uuid_string(char *buf, char *end, const u8 *addr,
char uuid[UUID_STRING_LEN + 1];
char *p = uuid;
int i;
- const u8 *index = uuid_be_index;
+ const u8 *index = uuid_index;
bool uc = false;
switch (*(++fmt)) {
case 'L':
uc = true; /* fall-through */
case 'l':
- index = uuid_le_index;
+ index = guid_index;
break;
case 'B':
uc = true;
--
2.11.0
^ permalink raw reply related
* [PATCH 04/16] uuid: don't export guid_index and uuid_index
From: Christoph Hellwig @ 2017-05-10 18:02 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells, Mimi Zohar,
Steven Whitehouse
In-Reply-To: <20170510180214.16852-1-hch-jcswGhMUV9g@public.gmane.org>
These are only used in uuid.c and vsprintf.c and aren't something modules
should use directly.
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
lib/uuid.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/lib/uuid.c b/lib/uuid.c
index f80dc63f6ca8..003bf6823003 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -22,9 +22,7 @@
#include <linux/random.h>
const u8 guid_index[16] = {3,2,1,0,5,4,7,6,8,9,10,11,12,13,14,15};
-EXPORT_SYMBOL(guid_index);
const u8 uuid_index[16] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
-EXPORT_SYMBOL(uuid_index);
/***************************************************************
* Random UUID interface
--
2.11.0
^ permalink raw reply related
* [PATCH 05/16] uuid: add the v1 layout to uuid_t
From: Christoph Hellwig @ 2017-05-10 18:02 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells, Mimi Zohar,
Steven Whitehouse
In-Reply-To: <20170510180214.16852-1-hch-jcswGhMUV9g@public.gmane.org>
Turn the content of uuid_t into a union and add the fields for the v1
interpretation to it.
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
include/uapi/linux/uuid.h | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/uuid.h b/include/uapi/linux/uuid.h
index 1a2914d8b225..1039d2f3e114 100644
--- a/include/uapi/linux/uuid.h
+++ b/include/uapi/linux/uuid.h
@@ -25,7 +25,34 @@ typedef struct {
} guid_t;
typedef struct {
- __u8 b[16];
+ union {
+ __u8 b[16];
+
+ /*
+ * V1 (time-based) UUID definition [RFC 4122]:
+ * - the timestamp is a 60-bit value, split 32/16/12, and goes
+ * in 100ns increments since midnight 15th October 1582
+ * - add UUID_TO_UNIX_TIME to convert unix time in 100ns
+ * units to UUID time
+ * - the clock sequence is a 14-bit counter to avoid duplicate
+ * times
+ */
+ struct {
+ __be32 time_low;
+ __be16 time_mid;
+ __be16 time_hi_and_version;
+#define UUID_TO_UNIX_TIME 0x01b21dd213814000ULL
+#define UUID_TIMEHI_MASK 0x0fff
+#define UUID_VERSION_TIME 0x1000 /* time-based UUID */
+#define UUID_VERSION_NAME 0x3000 /* name-based UUID */
+#define UUID_VERSION_RANDOM 0x4000 /* (pseudo-)random generated UUID */
+ u8 clock_seq_hi_and_reserved;
+#define UUID_CLOCKHI_MASK 0x3f
+#define UUID_VARIANT_STD 0x80
+ u8 clock_seq_low;
+ u8 node[6];
+ } v1;
+ };
} uuid_t;
#define GUID(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) \
--
2.11.0
^ permalink raw reply related
* [PATCH 06/16] afs: switch to use uuid_t and uuid_gen
From: Christoph Hellwig @ 2017-05-10 18:02 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells, Mimi Zohar,
Steven Whitehouse
In-Reply-To: <20170510180214.16852-1-hch-jcswGhMUV9g@public.gmane.org>
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
fs/afs/cmservice.c | 46 +++++++++++++++++++++++-----------------------
fs/afs/internal.h | 2 +-
fs/afs/main.c | 4 ++--
3 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/fs/afs/cmservice.c b/fs/afs/cmservice.c
index 3062cceb5c2a..d4e77d12570c 100644
--- a/fs/afs/cmservice.c
+++ b/fs/afs/cmservice.c
@@ -350,7 +350,7 @@ static int afs_deliver_cb_init_call_back_state3(struct afs_call *call)
{
struct sockaddr_rxrpc srx;
struct afs_server *server;
- struct uuid_v1 *r;
+ uuid_t *r;
unsigned loop;
__be32 *b;
int ret;
@@ -380,20 +380,20 @@ static int afs_deliver_cb_init_call_back_state3(struct afs_call *call)
}
_debug("unmarshall UUID");
- call->request = kmalloc(sizeof(struct uuid_v1), GFP_KERNEL);
+ call->request = kmalloc(sizeof(uuid_t), GFP_KERNEL);
if (!call->request)
return -ENOMEM;
b = call->buffer;
r = call->request;
- r->time_low = b[0];
- r->time_mid = htons(ntohl(b[1]));
- r->time_hi_and_version = htons(ntohl(b[2]));
- r->clock_seq_hi_and_reserved = ntohl(b[3]);
- r->clock_seq_low = ntohl(b[4]);
+ r->v1.time_low = b[0];
+ r->v1.time_mid = htons(ntohl(b[1]));
+ r->v1.time_hi_and_version = htons(ntohl(b[2]));
+ r->v1.clock_seq_hi_and_reserved = ntohl(b[3]);
+ r->v1.clock_seq_low = ntohl(b[4]);
for (loop = 0; loop < 6; loop++)
- r->node[loop] = ntohl(b[loop + 5]);
+ r->v1.node[loop] = ntohl(b[loop + 5]);
call->offset = 0;
call->unmarshall++;
@@ -453,7 +453,7 @@ static int afs_deliver_cb_probe(struct afs_call *call)
static void SRXAFSCB_ProbeUuid(struct work_struct *work)
{
struct afs_call *call = container_of(work, struct afs_call, work);
- struct uuid_v1 *r = call->request;
+ uuid_t *r = call->request;
struct {
__be32 match;
@@ -476,7 +476,7 @@ static void SRXAFSCB_ProbeUuid(struct work_struct *work)
*/
static int afs_deliver_cb_probe_uuid(struct afs_call *call)
{
- struct uuid_v1 *r;
+ uuid_t *r;
unsigned loop;
__be32 *b;
int ret;
@@ -502,20 +502,20 @@ static int afs_deliver_cb_probe_uuid(struct afs_call *call)
}
_debug("unmarshall UUID");
- call->request = kmalloc(sizeof(struct uuid_v1), GFP_KERNEL);
+ call->request = kmalloc(sizeof(uuid_t), GFP_KERNEL);
if (!call->request)
return -ENOMEM;
b = call->buffer;
r = call->request;
- r->time_low = b[0];
- r->time_mid = htons(ntohl(b[1]));
- r->time_hi_and_version = htons(ntohl(b[2]));
- r->clock_seq_hi_and_reserved = ntohl(b[3]);
- r->clock_seq_low = ntohl(b[4]);
+ r->v1.time_low = b[0];
+ r->v1.time_mid = htons(ntohl(b[1]));
+ r->v1.time_hi_and_version = htons(ntohl(b[2]));
+ r->v1.clock_seq_hi_and_reserved = ntohl(b[3]);
+ r->v1.clock_seq_low = ntohl(b[4]);
for (loop = 0; loop < 6; loop++)
- r->node[loop] = ntohl(b[loop + 5]);
+ r->v1.node[loop] = ntohl(b[loop + 5]);
call->offset = 0;
call->unmarshall++;
@@ -568,13 +568,13 @@ static void SRXAFSCB_TellMeAboutYourself(struct work_struct *work)
memset(&reply, 0, sizeof(reply));
reply.ia.nifs = htonl(nifs);
- reply.ia.uuid[0] = afs_uuid.time_low;
- reply.ia.uuid[1] = htonl(ntohs(afs_uuid.time_mid));
- reply.ia.uuid[2] = htonl(ntohs(afs_uuid.time_hi_and_version));
- reply.ia.uuid[3] = htonl((s8) afs_uuid.clock_seq_hi_and_reserved);
- reply.ia.uuid[4] = htonl((s8) afs_uuid.clock_seq_low);
+ reply.ia.uuid[0] = afs_uuid.v1.time_low;
+ reply.ia.uuid[1] = htonl(ntohs(afs_uuid.v1.time_mid));
+ reply.ia.uuid[2] = htonl(ntohs(afs_uuid.v1.time_hi_and_version));
+ reply.ia.uuid[3] = htonl((s8) afs_uuid.v1.clock_seq_hi_and_reserved);
+ reply.ia.uuid[4] = htonl((s8) afs_uuid.v1.clock_seq_low);
for (loop = 0; loop < 6; loop++)
- reply.ia.uuid[loop + 5] = htonl((s8) afs_uuid.node[loop]);
+ reply.ia.uuid[loop + 5] = htonl((s8) afs_uuid.v1.node[loop]);
if (ifs) {
for (loop = 0; loop < nifs; loop++) {
diff --git a/fs/afs/internal.h b/fs/afs/internal.h
index 393672997cc2..7de45c8686a2 100644
--- a/fs/afs/internal.h
+++ b/fs/afs/internal.h
@@ -544,7 +544,7 @@ extern int afs_drop_inode(struct inode *);
* main.c
*/
extern struct workqueue_struct *afs_wq;
-extern struct uuid_v1 afs_uuid;
+extern uuid_t afs_uuid;
/*
* misc.c
diff --git a/fs/afs/main.c b/fs/afs/main.c
index 51d7d17bca57..75b3d3a8b1ba 100644
--- a/fs/afs/main.c
+++ b/fs/afs/main.c
@@ -31,7 +31,7 @@ static char *rootcell;
module_param(rootcell, charp, 0);
MODULE_PARM_DESC(rootcell, "root AFS cell name and VL server IP addr list");
-struct uuid_v1 afs_uuid;
+uuid_t afs_uuid;
struct workqueue_struct *afs_wq;
/*
@@ -43,7 +43,7 @@ static int __init afs_init(void)
printk(KERN_INFO "kAFS: Red Hat AFS client v0.1 registering.\n");
- generate_random_uuid((unsigned char *)&afs_uuid);
+ uuid_gen(&afs_uuid);
/* create workqueue */
ret = -ENOMEM;
--
2.11.0
^ permalink raw reply related
* [PATCH 07/16] uuid: remove struct uuid_v1
From: Christoph Hellwig @ 2017-05-10 18:02 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells, Mimi Zohar,
Steven Whitehouse
In-Reply-To: <20170510180214.16852-1-hch-jcswGhMUV9g@public.gmane.org>
Unused now.
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
include/linux/uuid.h | 24 ------------------------
1 file changed, 24 deletions(-)
diff --git a/include/linux/uuid.h b/include/linux/uuid.h
index af669f317780..28a5a894b926 100644
--- a/include/linux/uuid.h
+++ b/include/linux/uuid.h
@@ -19,30 +19,6 @@
#include <uapi/linux/uuid.h>
/*
- * V1 (time-based) UUID definition [RFC 4122].
- * - the timestamp is a 60-bit value, split 32/16/12, and goes in 100ns
- * increments since midnight 15th October 1582
- * - add AFS_UUID_TO_UNIX_TIME to convert unix time in 100ns units to UUID
- * time
- * - the clock sequence is a 14-bit counter to avoid duplicate times
- */
-struct uuid_v1 {
- __be32 time_low; /* low part of timestamp */
- __be16 time_mid; /* mid part of timestamp */
- __be16 time_hi_and_version; /* high part of timestamp and version */
-#define UUID_TO_UNIX_TIME 0x01b21dd213814000ULL
-#define UUID_TIMEHI_MASK 0x0fff
-#define UUID_VERSION_TIME 0x1000 /* time-based UUID */
-#define UUID_VERSION_NAME 0x3000 /* name-based UUID */
-#define UUID_VERSION_RANDOM 0x4000 /* (pseudo-)random generated UUID */
- u8 clock_seq_hi_and_reserved; /* clock seq hi and variant */
-#define UUID_CLOCKHI_MASK 0x3f
-#define UUID_VARIANT_STD 0x80
- u8 clock_seq_low; /* clock seq low */
- u8 node[6]; /* spatially unique node ID (MAC addr) */
-};
-
-/*
* The length of a UUID string ("aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee")
* not including trailing NUL.
*/
--
2.11.0
^ permalink raw reply related
* [PATCH 08/16] xfs: remove uuid_getnodeuniq and xfs_uu_t
From: Christoph Hellwig @ 2017-05-10 18:02 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells, Mimi Zohar,
Steven Whitehouse
In-Reply-To: <20170510180214.16852-1-hch-jcswGhMUV9g@public.gmane.org>
Directly use the v1 intepretation of uuid_t instead.
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
fs/xfs/uuid.c | 25 -------------------------
fs/xfs/uuid.h | 1 -
fs/xfs/xfs_mount.c | 6 +++++-
3 files changed, 5 insertions(+), 27 deletions(-)
diff --git a/fs/xfs/uuid.c b/fs/xfs/uuid.c
index b83f76b6d410..937deaf2128d 100644
--- a/fs/xfs/uuid.c
+++ b/fs/xfs/uuid.c
@@ -17,31 +17,6 @@
*/
#include <xfs.h>
-/* IRIX interpretation of an uuid_t */
-typedef struct {
- __be32 uu_timelow;
- __be16 uu_timemid;
- __be16 uu_timehi;
- __be16 uu_clockseq;
- __be16 uu_node[3];
-} xfs_uu_t;
-
-/*
- * uuid_getnodeuniq - obtain the node unique fields of a UUID.
- *
- * This is not in any way a standard or condoned UUID function;
- * it just something that's needed for user-level file handles.
- */
-void
-uuid_getnodeuniq(uuid_t *uuid, int fsid [2])
-{
- xfs_uu_t *uup = (xfs_uu_t *)uuid;
-
- fsid[0] = (be16_to_cpu(uup->uu_clockseq) << 16) |
- be16_to_cpu(uup->uu_timemid);
- fsid[1] = be32_to_cpu(uup->uu_timelow);
-}
-
int
uuid_is_nil(uuid_t *uuid)
{
diff --git a/fs/xfs/uuid.h b/fs/xfs/uuid.h
index 4f1441ba4fa5..65b5cebf2f99 100644
--- a/fs/xfs/uuid.h
+++ b/fs/xfs/uuid.h
@@ -20,7 +20,6 @@
extern int uuid_is_nil(uuid_t *uuid);
extern int uuid_equal(uuid_t *uuid1, uuid_t *uuid2);
-extern void uuid_getnodeuniq(uuid_t *uuid, int fsid [2]);
static inline void
uuid_copy(uuid_t *dst, uuid_t *src)
diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
index 2eaf81859166..742e4a61c0bc 100644
--- a/fs/xfs/xfs_mount.c
+++ b/fs/xfs/xfs_mount.c
@@ -793,7 +793,11 @@ xfs_mountfs(
* Copies the low order bits of the timestamp and the randomly
* set "sequence" number out of a UUID.
*/
- uuid_getnodeuniq(&sbp->sb_uuid, mp->m_fixedfsid);
+ mp->m_fixedfsid[0] =
+ ((u32)sbp->sb_uuid.v1.clock_seq_hi_and_reserved << 24) |
+ ((u32)sbp->sb_uuid.v1.clock_seq_low << 16) |
+ be16_to_cpu(sbp->sb_uuid.v1.time_mid);
+ mp->m_fixedfsid[1] = be32_to_cpu(sbp->sb_uuid.v1.time_low);
mp->m_dmevmask = 0; /* not persistent; set after each mount */
--
2.11.0
^ permalink raw reply related
* [PATCH 09/16] md: namespace private helper names
From: Christoph Hellwig @ 2017-05-10 18:02 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein, linux-fsdevel
Cc: Shaohua Li, Dan Williams, David Howells, Steven Whitehouse,
Mimi Zohar, linux-xfs, linux-raid, linux-nvdimm, linux-kernel
In-Reply-To: <20170510180214.16852-1-hch@lst.de>
From: Amir Goldstein <amir73il@gmail.com>
The md private helper uuid_equal() collides with a generic helper
of the same name.
Rename the md private helper to md_uuid_equal() and do the same for
md_sb_equal().
Cc: Shaohua Li <shli@kernel.org>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/md/md.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 82f798be964f..65795cc4cb7d 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -825,7 +825,7 @@ static int read_disk_sb(struct md_rdev *rdev, int size)
return -EINVAL;
}
-static int uuid_equal(mdp_super_t *sb1, mdp_super_t *sb2)
+static int md_uuid_equal(mdp_super_t *sb1, mdp_super_t *sb2)
{
return sb1->set_uuid0 == sb2->set_uuid0 &&
sb1->set_uuid1 == sb2->set_uuid1 &&
@@ -833,7 +833,7 @@ static int uuid_equal(mdp_super_t *sb1, mdp_super_t *sb2)
sb1->set_uuid3 == sb2->set_uuid3;
}
-static int sb_equal(mdp_super_t *sb1, mdp_super_t *sb2)
+static int md_sb_equal(mdp_super_t *sb1, mdp_super_t *sb2)
{
int ret;
mdp_super_t *tmp1, *tmp2;
@@ -1025,12 +1025,12 @@ static int super_90_load(struct md_rdev *rdev, struct md_rdev *refdev, int minor
} else {
__u64 ev1, ev2;
mdp_super_t *refsb = page_address(refdev->sb_page);
- if (!uuid_equal(refsb, sb)) {
+ if (!md_uuid_equal(refsb, sb)) {
pr_warn("md: %s has different UUID to %s\n",
b, bdevname(refdev->bdev,b2));
goto abort;
}
- if (!sb_equal(refsb, sb)) {
+ if (!md_sb_equal(refsb, sb)) {
pr_warn("md: %s has same UUID but different superblock to %s\n",
b, bdevname(refdev->bdev, b2));
goto abort;
--
2.11.0
^ permalink raw reply related
* [PATCH 10/16] uuid: hoist helpers uuid_equal() and uuid_copy() from xfs
From: Christoph Hellwig @ 2017-05-10 18:02 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells, Mimi Zohar,
Steven Whitehouse
In-Reply-To: <20170510180214.16852-1-hch-jcswGhMUV9g@public.gmane.org>
From: Amir Goldstein <amir73il-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
These helper are used to compare and copy two uuid_t type objects.
Signed-off-by: Amir Goldstein <amir73il-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[hch: also provide the respective guid_ versions]
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
fs/xfs/uuid.c | 6 ------
fs/xfs/uuid.h | 7 -------
include/linux/uuid.h | 20 ++++++++++++++++++++
3 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/fs/xfs/uuid.c b/fs/xfs/uuid.c
index 937deaf2128d..737c186ea98b 100644
--- a/fs/xfs/uuid.c
+++ b/fs/xfs/uuid.c
@@ -30,9 +30,3 @@ uuid_is_nil(uuid_t *uuid)
if (*cp++) return 0; /* not nil */
return 1; /* is nil */
}
-
-int
-uuid_equal(uuid_t *uuid1, uuid_t *uuid2)
-{
- return memcmp(uuid1, uuid2, sizeof(uuid_t)) ? 0 : 1;
-}
diff --git a/fs/xfs/uuid.h b/fs/xfs/uuid.h
index 65b5cebf2f99..5aea49bf0963 100644
--- a/fs/xfs/uuid.h
+++ b/fs/xfs/uuid.h
@@ -19,12 +19,5 @@
#define __XFS_SUPPORT_UUID_H__
extern int uuid_is_nil(uuid_t *uuid);
-extern int uuid_equal(uuid_t *uuid1, uuid_t *uuid2);
-
-static inline void
-uuid_copy(uuid_t *dst, uuid_t *src)
-{
- memcpy(dst, src, sizeof(uuid_t));
-}
#endif /* __XFS_SUPPORT_UUID_H__ */
diff --git a/include/linux/uuid.h b/include/linux/uuid.h
index 28a5a894b926..b7fec8b266eb 100644
--- a/include/linux/uuid.h
+++ b/include/linux/uuid.h
@@ -29,11 +29,31 @@ static inline int guid_cmp(const guid_t u1, const guid_t u2)
return memcmp(&u1, &u2, sizeof(guid_t));
}
+static inline bool guid_equal(const guid_t *u1, const guid_t *u2)
+{
+ return memcmp(u1, u2, sizeof(guid_t)) == 0;
+}
+
+static inline void guid_copy(guid_t *dst, const guid_t *src)
+{
+ memcpy(dst, src, sizeof(guid_t));
+}
+
static inline int uuid_cmp(const uuid_t u1, const uuid_t u2)
{
return memcmp(&u1, &u2, sizeof(uuid_t));
}
+static inline bool uuid_equal(const uuid_t *u1, const uuid_t *u2)
+{
+ return memcmp(u1, u2, sizeof(uuid_t)) == 0;
+}
+
+static inline void uuid_copy(uuid_t *dst, const uuid_t *src)
+{
+ memcpy(dst, src, sizeof(uuid_t));
+}
+
void generate_random_uuid(unsigned char uuid[16]);
extern void guid_gen(guid_t *u);
--
2.11.0
^ permalink raw reply related
* [PATCH 11/16] uuid: hoist uuid_is_null() helper from libnvdimm
From: Christoph Hellwig @ 2017-05-10 18:02 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells, Mimi Zohar,
Steven Whitehouse
In-Reply-To: <20170510180214.16852-1-hch-jcswGhMUV9g@public.gmane.org>
From: Amir Goldstein <amir73il-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hoist the libnvdimm helper as an inline helper to linux/uuid.h
using an auxiliary const variable uuid_null in lib/uuid.c.
[hch: also add the guid variant. Both do the same but I'd like
to keep casts to a minimum]
The common helper uses the new abstract type uuid_t * instead of
u8 *.
Suggested-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Cc: Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Amir Goldstein <amir73il-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[hch: added guid_is_null]
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
drivers/nvdimm/btt_devs.c | 9 +--------
include/linux/uuid.h | 13 +++++++++++++
lib/uuid.c | 5 +++++
3 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/nvdimm/btt_devs.c b/drivers/nvdimm/btt_devs.c
index 4b76af2b8715..734290d30557 100644
--- a/drivers/nvdimm/btt_devs.c
+++ b/drivers/nvdimm/btt_devs.c
@@ -222,13 +222,6 @@ struct device *nd_btt_create(struct nd_region *nd_region)
return dev;
}
-static bool uuid_is_null(u8 *uuid)
-{
- static const u8 null_uuid[16];
-
- return (memcmp(uuid, null_uuid, 16) == 0);
-}
-
/**
* nd_btt_arena_is_valid - check if the metadata layout is valid
* @nd_btt: device with BTT geometry and backing device info
@@ -249,7 +242,7 @@ bool nd_btt_arena_is_valid(struct nd_btt *nd_btt, struct btt_sb *super)
if (memcmp(super->signature, BTT_SIG, BTT_SIG_LEN) != 0)
return false;
- if (!uuid_is_null(super->parent_uuid))
+ if (!guid_is_null((guid_t *)&super->parent_uuid))
if (memcmp(super->parent_uuid, parent_uuid, 16) != 0)
return false;
diff --git a/include/linux/uuid.h b/include/linux/uuid.h
index b7fec8b266eb..2f9bdc88079e 100644
--- a/include/linux/uuid.h
+++ b/include/linux/uuid.h
@@ -24,6 +24,9 @@
*/
#define UUID_STRING_LEN 36
+extern const guid_t guid_null;
+extern const uuid_t uuid_null;
+
static inline int guid_cmp(const guid_t u1, const guid_t u2)
{
return memcmp(&u1, &u2, sizeof(guid_t));
@@ -39,6 +42,11 @@ static inline void guid_copy(guid_t *dst, const guid_t *src)
memcpy(dst, src, sizeof(guid_t));
}
+static inline bool guid_is_null(guid_t *guid)
+{
+ return guid_equal(guid, &guid_null);
+}
+
static inline int uuid_cmp(const uuid_t u1, const uuid_t u2)
{
return memcmp(&u1, &u2, sizeof(uuid_t));
@@ -54,6 +62,11 @@ static inline void uuid_copy(uuid_t *dst, const uuid_t *src)
memcpy(dst, src, sizeof(uuid_t));
}
+static inline bool uuid_is_null(uuid_t *uuid)
+{
+ return uuid_equal(uuid, &uuid_null);
+}
+
void generate_random_uuid(unsigned char uuid[16]);
extern void guid_gen(guid_t *u);
diff --git a/lib/uuid.c b/lib/uuid.c
index 003bf6823003..25145bfb0eaa 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -21,6 +21,11 @@
#include <linux/uuid.h>
#include <linux/random.h>
+const guid_t guid_null;
+EXPORT_SYMBOL(guid_null);
+const uuid_t uuid_null;
+EXPORT_SYMBOL(uuid_null);
+
const u8 guid_index[16] = {3,2,1,0,5,4,7,6,8,9,10,11,12,13,14,15};
const u8 uuid_index[16] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
--
2.11.0
^ permalink raw reply related
* [PATCH 12/16] xfs: use the common helper uuid_is_null()
From: Christoph Hellwig @ 2017-05-10 18:02 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells, Mimi Zohar,
Steven Whitehouse
In-Reply-To: <20170510180214.16852-1-hch-jcswGhMUV9g@public.gmane.org>
From: Amir Goldstein <amir73il-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Use the common helper uuid_is_null() and remove the xfs specific
helper uuid_is_nil().
The common helper does not check for the NULL pointer value as
xfs helper did, but xfs code never calls the helper with a pointer
that can be NULL.
Conform comments and warning strings to use the term 'null uuid'
instead of 'nil uuid', because this is the terminology used by
lib/uuid.c and its users. It is also the terminology used in
userspace by libuuid and xfsprogs.
Signed-off-by: Amir Goldstein <amir73il-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[hch: remove now unused uuid.[ch]]
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
fs/xfs/Makefile | 3 +--
fs/xfs/uuid.c | 32 --------------------------------
fs/xfs/uuid.h | 23 -----------------------
fs/xfs/xfs_linux.h | 1 -
fs/xfs/xfs_log_recover.c | 6 +++---
fs/xfs/xfs_mount.c | 8 ++++----
6 files changed, 8 insertions(+), 65 deletions(-)
delete mode 100644 fs/xfs/uuid.c
delete mode 100644 fs/xfs/uuid.h
diff --git a/fs/xfs/Makefile b/fs/xfs/Makefile
index 5c90f82b8f6b..a6e955bfead8 100644
--- a/fs/xfs/Makefile
+++ b/fs/xfs/Makefile
@@ -98,8 +98,7 @@ xfs-y += xfs_aops.o \
xfs_sysfs.o \
xfs_trans.o \
xfs_xattr.o \
- kmem.o \
- uuid.o
+ kmem.o
# low-level transaction/log code
xfs-y += xfs_log.o \
diff --git a/fs/xfs/uuid.c b/fs/xfs/uuid.c
deleted file mode 100644
index 737c186ea98b..000000000000
--- a/fs/xfs/uuid.c
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * Copyright (c) 2000-2003,2005 Silicon Graphics, Inc.
- * All Rights Reserved.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it would be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write the Free Software Foundation,
- * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
- */
-#include <xfs.h>
-
-int
-uuid_is_nil(uuid_t *uuid)
-{
- int i;
- char *cp = (char *)uuid;
-
- if (uuid == NULL)
- return 0;
- /* implied check of version number here... */
- for (i = 0; i < sizeof *uuid; i++)
- if (*cp++) return 0; /* not nil */
- return 1; /* is nil */
-}
diff --git a/fs/xfs/uuid.h b/fs/xfs/uuid.h
deleted file mode 100644
index 5aea49bf0963..000000000000
--- a/fs/xfs/uuid.h
+++ /dev/null
@@ -1,23 +0,0 @@
-/*
- * Copyright (c) 2000-2003,2005 Silicon Graphics, Inc.
- * All Rights Reserved.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it would be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write the Free Software Foundation,
- * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
- */
-#ifndef __XFS_SUPPORT_UUID_H__
-#define __XFS_SUPPORT_UUID_H__
-
-extern int uuid_is_nil(uuid_t *uuid);
-
-#endif /* __XFS_SUPPORT_UUID_H__ */
diff --git a/fs/xfs/xfs_linux.h b/fs/xfs/xfs_linux.h
index 2c33d915e550..2d167fe643ec 100644
--- a/fs/xfs/xfs_linux.h
+++ b/fs/xfs/xfs_linux.h
@@ -43,7 +43,6 @@ typedef __u32 xfs_nlink_t;
#include "kmem.h"
#include "mrlock.h"
-#include "uuid.h"
#include <linux/semaphore.h>
#include <linux/mm.h>
diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c
index cd0b077deb35..8cec1e5505a4 100644
--- a/fs/xfs/xfs_log_recover.c
+++ b/fs/xfs/xfs_log_recover.c
@@ -352,13 +352,13 @@ xlog_header_check_mount(
{
ASSERT(head->h_magicno == cpu_to_be32(XLOG_HEADER_MAGIC_NUM));
- if (uuid_is_nil(&head->h_fs_uuid)) {
+ if (uuid_is_null(&head->h_fs_uuid)) {
/*
* IRIX doesn't write the h_fs_uuid or h_fmt fields. If
- * h_fs_uuid is nil, we assume this log was last mounted
+ * h_fs_uuid is null, we assume this log was last mounted
* by IRIX and continue.
*/
- xfs_warn(mp, "nil uuid in log - IRIX style log");
+ xfs_warn(mp, "null uuid in log - IRIX style log");
} else if (unlikely(!uuid_equal(&mp->m_sb.sb_uuid, &head->h_fs_uuid))) {
xfs_warn(mp, "log has mismatched uuid - can't recover");
xlog_header_check_dump(mp, head);
diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
index 742e4a61c0bc..682b336a7a6a 100644
--- a/fs/xfs/xfs_mount.c
+++ b/fs/xfs/xfs_mount.c
@@ -80,14 +80,14 @@ xfs_uuid_mount(
if (mp->m_flags & XFS_MOUNT_NOUUID)
return 0;
- if (uuid_is_nil(uuid)) {
- xfs_warn(mp, "Filesystem has nil UUID - can't mount");
+ if (uuid_is_null(uuid)) {
+ xfs_warn(mp, "Filesystem has null UUID - can't mount");
return -EINVAL;
}
mutex_lock(&xfs_uuid_table_mutex);
for (i = 0, hole = -1; i < xfs_uuid_table_size; i++) {
- if (uuid_is_nil(&xfs_uuid_table[i])) {
+ if (uuid_is_null(&xfs_uuid_table[i])) {
hole = i;
continue;
}
@@ -124,7 +124,7 @@ xfs_uuid_unmount(
mutex_lock(&xfs_uuid_table_mutex);
for (i = 0; i < xfs_uuid_table_size; i++) {
- if (uuid_is_nil(&xfs_uuid_table[i]))
+ if (uuid_is_null(&xfs_uuid_table[i]))
continue;
if (!uuid_equal(uuid, &xfs_uuid_table[i]))
continue;
--
2.11.0
^ permalink raw reply related
* [PATCH 13/16] block: remove blk_part_pack_uuid
From: Christoph Hellwig @ 2017-05-10 18:02 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells, Mimi Zohar,
Steven Whitehouse
In-Reply-To: <20170510180214.16852-1-hch-jcswGhMUV9g@public.gmane.org>
This helper was only used by IMA of all things, which would get spurious
errors if CONFIG_BLOCK is disabled. Just opencode the call there.
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
include/linux/genhd.h | 11 -----------
security/integrity/ima/ima_policy.c | 6 ++----
2 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index acff9437e5c3..e619fae2f037 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -219,12 +219,6 @@ static inline struct gendisk *part_to_disk(struct hd_struct *part)
return NULL;
}
-static inline int blk_part_pack_uuid(const u8 *uuid_str, u8 *to)
-{
- uuid_be_to_bin(uuid_str, (uuid_be *)to);
- return 0;
-}
-
static inline int disk_max_parts(struct gendisk *disk)
{
if (disk->flags & GENHD_FL_EXT_DEVT)
@@ -736,11 +730,6 @@ static inline dev_t blk_lookup_devt(const char *name, int partno)
dev_t devt = MKDEV(0, 0);
return devt;
}
-
-static inline int blk_part_pack_uuid(const u8 *uuid_str, u8 *to)
-{
- return -EINVAL;
-}
#endif /* CONFIG_BLOCK */
#endif /* _LINUX_GENHD_H */
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index 3ab1067db624..4d1178610145 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -717,10 +717,8 @@ static int ima_parse_rule(char *rule, struct ima_rule_entry *entry)
break;
}
- result = blk_part_pack_uuid(args[0].from,
- entry->fsuuid);
- if (!result)
- entry->flags |= IMA_FSUUID;
+ uuid_to_bin(args[0].from, (uuid_t *)entry->fsuuid);
+ entry->flags |= IMA_FSUUID;
break;
case Opt_uid_gt:
case Opt_euid_gt:
--
2.11.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox