On Thu, Nov 04, 2021 at 11:10:19AM -0700, Dan Williams wrote: > On Thu, Nov 4, 2021 at 10:36 AM Christoph Hellwig <hch@xxxxxx> wrote: > > > > On Thu, Nov 04, 2021 at 10:34:17AM -0700, Darrick J. Wong wrote: > > > /me wonders, are block devices going away? Will mkfs.xfs have to learn > > > how to talk to certain chardevs? I guess jffs2 and others already do > > > that kind of thing... but I suppose I can wait for the real draft to > > > show up to ramble further. ;) > > > > Right now I've mostly been looking into the kernel side. An no, I > > do not expect /dev/pmem* to go away as you'll still need it for a > > not DAX aware file system and/or application (such as mkfs initially). > > > > But yes, just pointing mkfs to the chardev should be doable with very > > little work. We can point it to a regular file after all. > > Note that I've avoided implementing read/write fops for dax devices > partly out of concern for not wanting to figure out shared-mmap vs > write coherence issues, but also because of a bet with Dave Hansen > that device-dax not grow features like what happened to hugetlbfs. So > it would seem mkfs would need to switch to mmap I/O, or bite the > bullet and implement read/write fops in the driver. That ... would require a fair amount of userspace changes, though at least e2fsprogs has pluggable io drivers, which would make mmapping a character device not too awful. xfsprogs would be another story -- porting the buffer cache mignt not be too bad, but mkfs and repair seem to issue pread/pwrite calls directly. Note that xfsprogs explicitly screens out chardevs. --D -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
