On 02/27/2015 02:58 AM, Dave Chinner wrote: <> >> >> Sigh, thanks Dave. Yes you are correct my patch enabled the >> udev events, as part of fixing ramdisk with partitions. >> This is because if you do not enable them then mount by UUID >> and all sort of lsblk and friends do not work. > > Sure, that's what the gendisk abstraction just you. But why am I > seeing random partition probes on a ramdisk that *isn't using > partitions*? > Yes, There should be the one new event on create (modprobe or mknod) which was not there before. Perhaps it triggers a systemd process that never used to run before. (And is now sitting there and making a mess) <> >> It looks like the system anticipates that ramdisk "should >> not have these events" > > Right, but not because it's a ramdisk. Those events should not be > occurring because I'm not creating or destroying devices, I'm not > changing partition tables, I'm not resizing ramdisks or partitions, > and so on. I'm simply mkfs'ing, mounting and unmounting filesystems > on the ramdisks - nothing should be generating device based udev > events... > > Finding the trigger that is causing these events will tell us what > the bug is - > restricting the config won't help, especially as DAX > will *always* be enabled on my test machines as it's something > needed in my test matrix. No the "if DAX" is for the 4k thing. The enablement of the uevents is with a new "part_show" module parameter (See patch-1). > I'm not sure how to go about finding that > trigger right now and as such I won't really have time to look at it > until after lsfmm/vault... > I'll try to reproduce this here. What Fedora version do I need? > Cheers, > Dave. > Thanks Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
