UFS(2) portable driver for other OS

[CeDeROM]

Hello :-)

Some time ago I have definitely moved from EXT2 to UFS2. This greatly
improved my speed and stability on FreeBSD, but I somehow lost access
and portability for other OS in "native" read-write mode. I am looking
for an universal fs driver for other OS mainly Linux and Windows that
would allow me to use UFS(2) natively (such as ext2fsd). I am sure
there is already such solution, as fs standard is open and BSD
licensed, so other OS would surely benefit from that support/driver
:-)

Please advise :-)
Tomek

[Polytropon]

Post by CeDeROM
Hello :-)
Some time ago I have definitely moved from EXT2 to UFS2. This greatly
improved my speed and stability on FreeBSD, but I somehow lost access
and portability for other OS in "native" read-write mode.

The lowest common denominator is msdosfs (DOS FAT) which is
usable in r/w nearly everywhere. If you require long file
names, you need the 16 bit version. This is commonly considered
the "typical solution" for the problem you're describing, even
though it doesn't really look any attractive because, as I
said, it's the _lowest_ common denominator where "lowest" is
determined by the inability of "Windows" products to be
willing to accept anything that isn't made, approved, certified
and sold by MICROS~1. :-)

Post by CeDeROM
I am looking
for an universal fs driver for other OS mainly Linux and Windows that
would allow me to use UFS(2) natively (such as ext2fsd).

The _most universal_ file system isn't even a file system.
Instead, it's tar. Yes, really: "tar-formatted" media can
be read almost everywhere (DOS, IRIX, Solaris, BSD, Linux,
AIX etc.). Everything you need is a tar implementation on
the target system. It works with almost all media (floppy
disks, CD, DVD, USB drives, SD cards, even hard disks).
The major downside is that it isn't really a file system.
It's good for transfer from A to B, but not for adding,
changing or removing files...

Post by CeDeROM
I am sure
there is already such solution, as fs standard is open and BSD
licensed, so other OS would surely benefit from that support/driver
:-)

No, something like that doesn't exist because nobody cares
about interoperability of data. :-)

[CeDeROM]

Post by Polytropon

Post by CeDeROM
Hello :-)
Some time ago I have definitely moved from EXT2 to UFS2. This greatly
improved my speed and stability on FreeBSD, but I somehow lost access
and portability for other OS in "native" read-write mode.

The lowest common denominator is msdosfs (DOS FAT) which is
usable in r/w nearly everywhere. If you require long file
names, you need the 16 bit version.

Hey Polytropon :-) I need large files over 4GB and some existing
access riight not to be modified so FAT does not apply, also extFAT is
patented so I wont give it even a try...

Post by Polytropon
The _most universal_ file system isn't even a file system.
Instead, it's tar. Yes, really: "tar-formatted" media can
(..)
It's good for transfer from A to B, but not for adding,
changing or removing files...

For archives maybe yes, but I need it as live r/w filesystem, just
like I used EXT2 - lets say three small OS partitions and one large
data partition on the workstation :-)

Post by Polytropon

Post by CeDeROM
I am sure
there is already such solution, as fs standard is open and BSD
licensed, so other OS would surely benefit from that support/driver
:-)

No, something like that doesn't exist because nobody cares
about interoperability of data. :-)

How about UFS2 driver for other OS? Is UFS2 endianness sensitive? Even
if, on one machine that would not be the problem :-)

Did anyone implement public UFS2 driver for other OS (Windows, Linux)?

Best regards :-)
Tomek

[Freddie Cash]

Post by Polytropon

Post by CeDeROM
Hello :-)
Some time ago I have definitely moved from EXT2 to UFS2. This greatly
improved my speed and stability on FreeBSD, but I somehow lost access
and portability for other OS in "native" read-write mode.

The lowest common denominator is msdosfs (DOS FAT) which is
usable in r/w nearly everywhere. If you require long file
names, you need the 16 bit version. This is commonly considered
the "typical solution" for the problem you're describing, even
though it doesn't really look any attractive because, as I
said, it's the _lowest_ common denominator where "lowest" is
determined by the inability of "Windows" products to be
willing to accept anything that isn't made, approved, certified
and sold by MICROS~1. :-)

There's also UDF which doesn't suffer from a lot of the issues the
FAT16/32/32x does on large-ish devices. FreeBSD, Windows, Linux, MacOSX
all support read/write to UDF, although it may depend on the OS version for
Windows (I think XP needs a 3rd party driver).​​

I've used UDF successfully on USB drives, although I don't think you can
boot off it.

[CeDeROM]

Post by Freddie Cash
There's also UDF which doesn't suffer from a lot of the issues the
FAT16/32/32x does on large-ish devices. FreeBSD, Windows, Linux, MacOSX
all support read/write to UDF, although it may depend on the OS version for
Windows (I think XP needs a 3rd party driver).
I've used UDF successfully on USB drives, although I don't think you can
boot off it.

Yess, thats what I need! Thank you Freddie, I will try it out!! :-)

No need to boot of data partition anyway.. and I remember some UDF
related issues on mkisofs port some time ago.. but this might be the
best solution also for data storage on a HD and seems non -endian
problematic :-) :-)

Best regards! :-)
Tomek

[CeDeROM]

Post by CeDeROM

Post by Freddie Cash
There's also UDF which doesn't suffer from a lot of the issues the
FAT16/32/32x does on large-ish devices. FreeBSD, Windows, Linux, MacOSX
all support read/write to UDF, although it may depend on the OS version for
Windows (I think XP needs a 3rd party driver).
I've used UDF successfully on USB drives, although I don't think you can
boot off it.

Yess, thats what I need! Thank you Freddie, I will try it out!! :-)

UDF disk does not work on FreeBSD :-(

I can create filesystem on a file, but not a memory disk (not
supported on my operating system yet). Then I cannot mount both of
them anyway.

Dead end for UDF disk on FreeBSD?

Is seems possible on Linux and Windows though:
http://tanguy.ortolo.eu/blog/article93/usb-udf



***@hexagon:~ # dd if=/dev/zero of=udf.bin bs=64k count=128k
131072+0 records in
131072+0 records out
8589934592 bytes transferred in 111.747670 secs (76869026 bytes/sec)
***@hexagon:~ # newfs_udf -L UDFTEST udf.bin
Opening device udf.bin

UDF device udf.bin is a regular file
bufcache thread initialising


Disc info for disc in device udf.bin
MMC profile : Unknown[0] profile
sequential : no
recordable : yes
erasable : no
blankable : no
formattable : no
rewritable : yes
mount raineer : no
packet writing : no
strict overwrite : no
blocking number : 1
disc state : random writable
last session state : incomplete
sectorsize : 512
Number of sessions 1
Session 0
start at 0
ends at 16777216
length for 16777216
next writable at 16777217
free blocks 0
packet size 64

Creating a filingsystem on a recordable rewritable CD-RW or
DVD+RW/DVD-RW or fixed length file
Free unallocated space on this volume 8587442688
Closing disc
Dismounting disc
syncing disc
syncing `4dc9e13a`:`00001674`:`UDFTEST`
syncing data
syncing nodes
used/freed space tables
Closing logical volume `4dc9e13a`:`00001674`:`UDFTEST`
wait for syncing disc to idle
stopping bufcache thread
bufcache thread joining
signal disc its finished with writing
wait for final disc idling
close device
Disc access statistics
sector reads 1 (0 Kbyte)
sector written 4267 (2133 Kbyte)
switches 3

***@hexagon:~ # dd if=/dev/zero of=udf2.bin bs=64k count=8k
8192+0 records in
8192+0 records out
536870912 bytes transferred in 7.191754 secs (74650899 bytes/sec)
***@hexagon:~ # mdconfig -a -f udf2.bin
md0
***@hexagon:~ # newfs_udf -L UDFTEST2 /dev/md0
Opening device /dev/md0

Got error executing SCSI command, assuming IDE disc
UDF: no explicit support for disc devices yet for this operating system.
: No such file or directory
Trying readonly access...
: No such file or directory
UDF: warning... reading/writing on 'disc' device
bufcache thread initialising


Disc info for disc in device /dev/md0
MMC profile : Unknown[0] profile
sequential : no
recordable : no
erasable : no
blankable : no
formattable : no
rewritable : no
mount raineer : no
packet writing : no
strict overwrite : no
blocking number : 1
disc state : random writable
last session state : complete/closed disc
sectorsize : 512
Number of sessions 1
Session 0
start at 0
ends at 0
length for 0
next writable at 0
free blocks 0
packet size 0

Can't create filingsystem on a non recordable disc
Closing disc
Dismounting disc
dismounting readonly disc
stopping bufcache thread
bufcache thread joining
Disc access statistics
sector reads 0 (0 Kbyte)
sector written 0 (0 Kbyte)
switches 0

***@hexagon:~ # mount_udf -v /dev/md0 /mnt/tmp
mount_udf: /dev/md0: Invalid argument
***@hexagon:~ # mdconfig -d -u 0

***@hexagon:~ # mount_udf -v udf.bin /mnt/tmp
mount_udf: udf.bin: Invalid argument
***@hexagon:~ # mdconfig -a -f udf.bin
***@hexagon:~ # mount_udf /dev/md0 /mnt/tmp
mount_udf: /dev/md0: Invalid argument

Did I miss anything? :-(

[Volodymyr Kostyrko]

Post by Freddie Cash

Post by Polytropon

Post by CeDeROM
Hello :-)
Some time ago I have definitely moved from EXT2 to UFS2. This greatly
improved my speed and stability on FreeBSD, but I somehow lost access
and portability for other OS in "native" read-write mode.

The lowest common denominator is msdosfs (DOS FAT) which is
usable in r/w nearly everywhere. If you require long file
names, you need the 16 bit version. This is commonly considered
the "typical solution" for the problem you're describing, even
though it doesn't really look any attractive because, as I
said, it's the _lowest_ common denominator where "lowest" is
determined by the inability of "Windows" products to be
willing to accept anything that isn't made, approved, certified
and sold by MICROS~1. :-)

There's also UDF which doesn't suffer from a lot of the issues the
FAT16/32/32x does on large-ish devices. FreeBSD, Windows, Linux, MacOSX
all support read/write to UDF, although it may depend on the OS version for
Windows (I think XP needs a 3rd party driver).​​

Waaaaait. This doesn't mean FreeBSD can mount UDF for read/write,
doesn't it?

[Freddie Cash]

Post by Freddie Cash

Post by Polytropon

Post by CeDeROM
Hello :-)
Some time ago I have definitely moved from EXT2 to UFS2. This greatly
improved my speed and stability on FreeBSD, but I somehow lost access
and portability for other OS in "native" read-write mode.

The lowest common denominator is msdosfs (DOS FAT) which is
usable in r/w nearly everywhere. If you require long file
names, you need the 16 bit version. This is commonly considered
the "typical solution" for the problem you're describing, even
though it doesn't really look any attractive because, as I
said, it's the _lowest_ common denominator where "lowest" is
determined by the inability of "Windows" products to be
willing to accept anything that isn't made, approved, certified
and sold by MICROS~1. :-)

There's also UDF which doesn't suffer from a lot of the issues the
FAT16/32/32x does on large-ish devices. FreeBSD, Windows, Linux, MacOSX
all support read/write to UDF, although it may depend on the OS version for
Windows (I think XP needs a 3rd party driver).​​

Waaaaait. This doesn't mean FreeBSD can mount UDF for read/write, doesn't
it?

I'd have to re-test it at home, but I'm pretty sure it worked on FreeBSD 9
as well.

[RW]

On Fri, 31 Jan 2014 15:06:01 +0100

Post by Polytropon

Post by CeDeROM
Hello :-)
Some time ago I have definitely moved from EXT2 to UFS2. This
greatly improved my speed and stability on FreeBSD, but I somehow
lost access and portability for other OS in "native" read-write
mode.

The lowest common denominator is msdosfs (DOS FAT) which is
usable in r/w nearly everywhere. If you require long file
names, you need the 16 bit version. This is commonly considered
the "typical solution" for the problem you're describing, even
though it doesn't really look any attractive because, as I
said, it's the _lowest_ common denominator where "lowest" is
determined by the inability of "Windows" products to be
willing to accept anything that isn't made, approved, certified
and sold by MICROS~1. :-)

In FreeBSD 10 the new fuse ntfs is much better than any previous ntfs
support. I use that for multimedia storage these days. So far it's
worked just fine on FreeBSD, Windows and my Samsung TV - I don't have
Linux but I doubt it's any worse. msdosfs may be more mature, but it's
still an accident waiting to happen.

[CeDeROM]

Post by RW
In FreeBSD 10 the new fuse ntfs is much better than any previous ntfs
support. I use that for multimedia storage these days. So far it's
worked just fine on FreeBSD, Windows and my Samsung TV - I don't have
Linux but I doubt it's any worse. msdosfs may be more mature, but it's
still an accident waiting to happen.

Thanks for hint :-) Some years ago fuse was not only crashing the
filesystem but also the machine :-P I will give it a try though :-)

My focus will go to UDF anyway as this seems to be the most "native"
filesystem on many platforms :-)

[Bernt Hansson]

Post by CeDeROM

Post by RW
In FreeBSD 10 the new fuse ntfs is much better than any previous ntfs
support. I use that for multimedia storage these days. So far it's
worked just fine on FreeBSD, Windows and my Samsung TV - I don't have
Linux but I doubt it's any worse. msdosfs may be more mature, but it's
still an accident waiting to happen.

Thanks for hint :-) Some years ago fuse was not only crashing the
filesystem but also the machine :-P I will give it a try though :-)
My focus will go to UDF anyway as this seems to be the most "native"
filesystem on many platforms :-)

Try this one

http://ffsdrv.sourceforge.net/index.php

[CeDeROM]

Post by RW
In FreeBSD 10 the new fuse ntfs is much better than any previous ntfs
support.

On a freshly ntfs formatted pendrive I get:

# mount -t ntfs-3g /dev/da0s1 /mnt/tmp
mount: /dev/da0s1: Operation not supported by device

:-(

[RW]

On Thu, 6 Feb 2014 14:02:57 +0100

Post by CeDeROM

Post by RW
In FreeBSD 10 the new fuse ntfs is much better than any previous
ntfs support.

# mount -t ntfs-3g /dev/da0s1 /mnt/tmp
mount: /dev/da0s1: Operation not supported by device

Do you have sysutils/fusefs-ntfs installed?

[CeDeROM]

Post by RW
On Thu, 6 Feb 2014 14:02:57 +0100

Post by CeDeROM
# mount -t ntfs-3g /dev/da0s1 /mnt/tmp
mount: /dev/da0s1: Operation not supported by device

Do you have sysutils/fusefs-ntfs installed?

Uhm, it was not installed, but, when installed I get the same error :-(

# mount -t ntfs-3g /dev/ada0s1 /mnt/tmp
mount: /dev/ada0s1: Operation not supported by device
***@mercury:~ # pkg info fusefs-ntfs
fusefs-ntfs-2012.1.15
Name : fusefs-ntfs
Version : 2012.1.15
Origin : sysutils/fusefs-ntfs
Architecture : freebsd:10:x86:64
Prefix : /usr/local
Categories : sysutils
Licenses : GPLv2
Maintainer : ***@FreeBSD.org
WWW : http://www.tuxera.com/community/ntfs-3g-download/
Comment : Mount NTFS partitions (read/write) and disk images
Options :
LOCK : on
UBLIO : on
Shared Libs required:
libublio.so.1
libntfs-3g.so.83
libfuse.so.2
Shared Libs provided:
libntfs-3g.so.83
Flat size : 1.57MiB
Description :
The ntfs-3g driver is an open source, freely available read/write NTFS
driver, which provides safe and fast handling of the Windows XP, Windows
Server 2003 and Windows 2000 filesystems. Almost the full POSIX filesystem
functionality is supported, the major exceptions are changing the file
ownerships and the access rights.

WWW: http://www.tuxera.com/community/ntfs-3g-download/

[CeDeROM]

Post by RW
In FreeBSD 10 the new fuse ntfs is much better than any previous ntfs
support. I use that for multimedia storage these days. So far it's
worked just fine on FreeBSD, Windows and my Samsung TV - I don't have
Linux but I doubt it's any worse. msdosfs may be more mature, but it's
still an accident waiting to happen.

I have switched to a new laptop and did NTFS as data storage
partition. For those few days I encountered several corruption
incidents. NTFS3G/FUSE still seems not reliable for everyday work :-(

I think porting UFS drivers for other OS, or better, porting a good
UDF driver to FreeBSD seems a good idea :-)

Best regards :-)
Tomek