Is UDF recommended for pandora (and pyra) sd cards?


asimov-solensan

Very Active Member
Joined
Jan 8, 2010
Messages
732
So you may kill me but after 15 years using linux just found this UDF filesystem.

I wanted to format a 128GB usb disk to something permission/user agnostic since I want to use in many places, some of them where I'm unable to change any configuration, or install anything.

exFAT seemed the way to go for me but noticed when running a VM from that USB that speed was stupidly slow, something really I have never seen, and we are talking of a USB3 and a stick that announces speeds over 100MB/s. Then checking I noticed that mount.exfat was using 100% CPU all the time. Therefor I went for the easiest way, NTFS.

Now it's working well but I don't want to depend on those proprietary formats and searching for an alternative came upon this:

https://en.wikipedia.org/wiki/Universal_Disk_Format

And now I wonder why I have been using fat32 on my removable media for so many time.

Now the questions are. Is it recommended to use for pyra and pandora cards?
Anyone has experience using it?
Is it really maintained somehow? There is so few info that seems abandoned to me.
 
UDF is primarily used for rewritable cdrw/dvdrw.
Nero IN-CD used that, and it was very convenient.
Dunno for classic usage.
 
It's in the kernel source somewhere, thus is it maintained - it's almost the gold standard.

I just created a dummy udf file and had a play with it:
Code:
dd if=/dev/zero of=~/tmp.udf bs=1M count=2
mkudffs --media-type hd ~/tmp.udf
sudo mount -t udf ~/tmp.udf /mnt

It works, but it seems I can only ever fit 999KB of data in my 2.0MB UDF filesystem. I've not tried bigger or smaller filesystems, nor do I especially plan to at the moment. But that might be a reason not to use it.

mkudffs comes from udftools in this system by the way, but I think it was part of the base package on Arch.

I've also not tried any of this on my Pandora yet. Should be fine for the Pyra running debian for sure though.
 
UDF is an overengineered monstrosity that never even tried to reduce filesystem overhead.

But set up correctly, it'll work pretty much anywhere, it sort-of does unicode, and it supports posix permissions, so...
 
Only handles UTF-16 as far as I can see. ext4 seems to handle emoji correctly at least, though you can't run that on windows very easily. But yeah, if UTF-16 is enough for you then that is a win.
 
No, it's not UTF-16, it's a subset of UTF-16. UTF-16 isn't a fixed length encoding etc. UDF can handle the unicode BMP, the lower 16 bits.
 
No, it's not UTF-16, it's a subset of UTF-16.
UDF uses the raw unicode code points, UTF-16 doesn't work like that - the encoding is incompatible.

UTF-16 doesn't even work like UTF-8, as the first UTF standard it's a horrible abomination suffering from terrible compatibility compromises...
 
Ah yeah, forgot that UTF-16 hasn't meant everything's 16 bits for far too long now, silly me. On linux at least if you give it a character that's longer than 16-bits (I used one in the SMP for testing), it chops off the higher bits resulting in a different character that shares the same bottom 16 bits.
 
Regarding your comments it doesn't feel that encouraging right now. I really don't know if I will give it a try at some point.
 
Back
Top