On 11/06/2018 07:38 AM, NeilBrown wrote:
On Mon, Nov 05 2018, Xiao Ni wrote:Hi all Now there is a customer request to add Added time in mdadm -E. For example: # mdadm --examine /dev/sdb1 |pr -tn 1 /dev/sdb1: 2 Magic : a92b4efc 3 Version : 1.2 4 Feature Map : 0x0 5 Array UUID : 4c22baaf:1bedd35e:ee135a1e:6ec770b8 6 Name : eveba16.wob.vw.vwg:0 7 Creation Time : Mon Mar 16 16:32:29 2015 8 Raid Level : raid6 9 Raid Devices : 8 10 11 Avail Dev Size : 11720779776 (5588.90 GiB 6001.04 GB) 12 Array Size : 35162336256 (33533.42 GiB 36006.23 GB) 13 Used Dev Size : 11720778752 (5588.90 GiB 6001.04 GB) 14 Data Offset : 262144 sectors 15 Super Offset : 8 sectors 16 Unused Space : before=261864 sectors, after=1024 sectors 17 State : clean 18 Device UUID : c013f194:536952b4:d7d21574:4469a58d 19 20 Update Time : Thu Sep 6 11:01:57 2018 ADD HERE: Device Added Time: Aug 15 12:13:14 2017 <----------------------------------- He can know when the disk is added through this item. If adding this item into superblock, it needs to add a new super block version. Now the super1 block version is 1.0 1.1 and 1.2. Maybe it needs to add 1.3 for this. Is it the right way to do this? If using a new feature flag, it needs to specify a specific argument when creating raid device. I'm not sure which way is better, or both are wrong?
Hi Neil
First question is : what exactly are the required semantics? Does the time stamp get updated when the disk is added as a spare, or only when added as an active device? If it is updated when added as a spare, what happens when a spare is migrated from one array to another by spare-sharing? Also, what happens if a disk is failed, removed, and re-added? Does that update the time stamp?
At first I want to add this feature for all semantics. But obviously I missed
some semantics as you said above.
Second question is : Why does the customer want this? How will it be used? We have a duty-of-care to make sure we don't provide functionality that doesn't make sense. If this is for some internal monitoring system (my first guess), maybe the timestamp doesn't need to be stored in the array at all. Many monitoring systems have a database, it could be stored in there. You could add a udev rule which notices when a device is added to an array, and records the uuid of the device, and the timestamp, in some database.
Yes. It's the reason I asked about this too. I'll try to let customer give a response here.
If there is a genuine benefit from putting the timestamp in the metadata, my first suggestion would be to use some of device_uuid. There is a standard uuid format which includes a timestamp. We could change to use that instead of just random numbers. We might need a feature flag to say "the uuid contains a timestamp", but we might not.
Thanks for the suggestion to the purpose very much. As you talked above, before
doing this we'll need to wait the customer to explain in detail. Best Regards Xiao
