This is somewhat out of the ordinary. After recently reading that UDF was a viable filesystem choice for removable storage for those looking for a cross-platform read/write filesystem free or archaic limitations, I decided to give it a try.
I created a UDF filesystem on my external 500 GB hard drive in the following fashion, being sure to observe the correct physical block size:
mkudffs --media-type=hd --blocksize=512 /dev/sdc
start=0, blocks=64, type=RESERVED
start=64, blocks=12, type=VRS
start=76, blocks=180, type=USPACE
start=256, blocks=1, type=ANCHOR
start=257, blocks=16, type=PVDS
start=273, blocks=1, type=LVID
start=274, blocks=976772637, type=PSPACE
start=976772911, blocks=1, type=ANCHOR
start=976772912, blocks=239, type=USPACE
start=976773151, blocks=16, type=RVDS
start=976773167, blocks=1, type=ANCHOR
NOTE: This is a UDF 2.01 filesystem (the Linux userland tools do not support 2.50 or 2.60).
I mounted it and confirmed with df that ~466 GiB was free (which is correct). I then proceeded to extract a large tar file I had prepared beforehand as backup. Alas, after filling it with 82 GiB of data, any further attempts to write to the filesystem yielded an ENOSPC error.
An identical report was filed by an Ubuntu user to no avail . I should add that the kernel version is 2.6.35 as used by the most recent release of the SystemRescueCd. I'll try testing with both a newer kernel and Windows 7, which has a mature UDF implementation.
I'm not sure what the theoretical maximum volume size is for UDF 2.01 - information is hard to come by - but Microsoft suggests that it can store 2^32 blocks . If my math is correct, that means that I should be able to create anything up to a 2 EiB filesystem based on my current technique.
In any case, Linux was quite happy to report the space as being available but doesn't appear inclined to allow much of it to be used.
Windows 7 works a charm, although I had to create a partition for it to pay any attention to the filesystem. I just copied in excess of 2 GiB of data to the drive and it performs very well. I made a point of using mkudffs again so that's not at fault.
This is a sad situation, given that UDF 2.01 has been around for over a decade. I'm not sure where to take this though.
Having established that Ben Fennema is the maintainer, I'll now endeavour to take this upstream (perhaps to the linux-fsdevel list).
Thanks, let us know how those conversations go.