On Sat 16 Mar 2019 at 10:49:19 (+0100), Pascal Hambourg wrote: > Le 11/03/2019 à 19:46, David Wright a écrit : > > On Sat 09 Mar 2019 at 20:31:36 (+0100), Pascal Hambourg wrote: > > > > > > I did not mean using UDF on opticals discs but on regular drives, just > > > as any other general purpose filesystem. I once considered using it > > > for file sharing between Windows and Linux instead of the usual FAT > > > and NTFS. Indeed UDF is natively supported as a read-write filesystem > > > by both Linux and Windows, natively supports POSIX permissions and > > > does not suffer from FAT file size limitations. And I was surprised to > > > discover that the label set by Windows was not the label read by Linux > > > and vice versa. > > > > Without reading a review of how it performs, I'd worry about using it > > as a general purpose filesystem. It sounds as if it's designed mainly > > for handling specific issues raised by particular devices. > > No, the "U" stands for "Universal" and its is designed for a broad > range of media, including hard disks. It just has special features for > optical media, but is not restricted to them. > > The format.exe utility in Windows has an option to format a drive or > partition with UDF, so this is really not an oddity. > > > I might be > > happier if it were integrated into the kernel rather than just a > > user application. > > What do you mean ? The UDF driver is integrated in the kernel (unlike > NTFS which requires a FUSE driver to enable full-featured writes). Not > to be confused with CD/DVD authoring software which have a different > purpose.
You're right: I hadn't appreciated that the udf module only gets loaded when you mount a UDF filesystem. It doesn't appear to be needed for reading the LABEL/UUID when a device is connected, so it remains absent from /proc/filesystems for example. But I *was* briefly caught out by the necessity of blanking the first MB of the device/partition before running mkudffs, which didn't help matters. (Reminds me of fighting with DOS over partition information.) Having read a little and experimented a little, I think I'll leave this format alone at least for a while. For USB sticks (and SD cards): sure, they might work with Windows and linux, but that's about it. They don't work in the car, nor in any of our TVs, nor cameras/phones. For spinning rust: I've read about erroneous 'space full' messages on large partitions, and the ongoing lack of any fsck tool. That could be a big problem with TB disks. > > > You wrote that the filesystem label was independent of any OS. > > > > No, I wrote "A filesystem that has a label, has that label regardless > > of any OS." In other words, if you hold a filesystem (on a device) in > > your hands, the label is still present, as a property of the > > filesystem, written there as a sequence of characters. > > > > This is in contrast to the string /dev/disk/by-label/LABEL which is > > effectively an artefact of the operating system, dependant on the > > device being connected to a particular type of OS, and not written > > anywhere on the device itself. > > I understand what you mean, but my point is that it does not make any > difference in practice. We know that: Cousin Stanley's disks mount successfully and so do Michael Stone's and mine. > Whatever intrinsic metadata is stored on the > device is irrelevant ; what actually matters is what metadata the > operating system uses as a label. If different operating systems use > different metadata as the label, then you cannot consider that the > label is independent of any operating systems. If an OS foo decides to use metadata bar as the "label" for a given device, then the information "bar" must appear on the device (or else "label" is being used in a metaphorical sense like in politics). All you've demonstrated in your example is that there might be more than one label, suiting different circumstances. In writing mkudffs, it appears that the authors have allowed easy avoidance of that problem by supplying an argument that sets both labels (here called identifiers) to the same string. A result is that linux (I haven't checked with Windows) will read that string as the value for LABEL. Going back to Cousin Stanley's point, the LABEL's value is bar, and I expressed the view that fstab's field 1 being set to "LABEL=bar" is more explicit than "/dev/disk/by-label/bar". If the "metadata the operating system uses as a label" bears no relation to the "intrinsic metadata is stored on the device" (for example, it might count the number of discs ever inserted into a reader, and use that number as the label), then I think the OS's designers might have difficulty justifying their decision. (If that example appears a stretch, it's because I'm having difficulty thinking of an example where a label isn't intended to be in or on something. Perhaps when it's been deliberately unpeeled or chiselled?) Cheers, David.
