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? 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? 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. 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. NeilBrown
Attachment:
signature.asc
Description: PGP signature
