NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: newfs_udf(8) and other OSes



Hello,

On Sat, Jun 27, 2015 at 07:13:04PM +0200, Benny Siegert wrote:
> On Sat, Jun 27, 2015 at 6:47 PM,  <tlaronde%polynum.com@localhost> wrote:
> > Since the ntfs-3g(8) driver has very poor performance with USB (and the
> > bottleneck is the driver, since formatting and using the device as an
> > UDF one the writing performance, even if not tremendous, is improved)
> > I'm trying to find if UDF can be used as a common filesystem to
> > allow to read---here---the same USB connected disk both under NetBSD
> > and under Windows.
> 
> Interesting idea!
> 
> > What is different is that the Windows selects 2048 bits as block size,
> > while newfs_udf is setting 512 bits.
> 
> newfs_udf allows setting "blocking size" and sector size with the -B
> and -S options. Maybe there is a combination of these that Windows
> will like?
> 

There are no such options for me on NetBSD 6.1.5 : size is ignored, and
-S is for label. Is there some update on -current?

> > Furthermore, fdisk(8) shows no MBR
> 
> Did you write on the "d" device, i.e. the whole thing? Windows and Mac
> OS prefer to have an MBR and partition table on a USB stick, as they
> consider it the same as a hard drive. However, see below.
> 
> > when using newfs_udf(8) while the Windows formatted shows the first
> > pseudo partition as a 238 aka "GPT Protective MBR".
> 
> So the stick has a GPT partition table, not an MBR. You will want to
> use gpt(8) to create one. (I would be interested in knowing which GPT
> partition type Windows uses for the GPT partition.) Something like
> 
> gpt create sd0
> gpt add -t windows sd0
> 

I have created a gpt: still not recognized on Windows.

Then, under Windows, I have formatted by specifying "/A:512" (not
documented in help) to create an UDF with 512 allocation blocks.

Then under NetBSD, gpt (gpt show -l sd0) gives:

       start        size  index  contents
           0           1         PMBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34        2014         
        2048  1953454080      1  GPT part - "Basic data partition"
  1953456128        2015         
  1953458143          32         Sec GPT table
  1953458175           1         Sec GPT header

The problem is now, I imagine, to create a "wedge" so that the UDF is
not searched at the very beginning but at block 2048.

But dkctl(8) doesn't help a lot: addwedge gives systematically "invalid
argument", without information, and, furthermore, udf is not listed as
a valid ptype (is cd9660 instead OK?).

Or have I to create a disklabel explicitely creating at partition at
2048 offset?

Nonetheless, thanks for your help!

I hope that by gathering the tips from different people we will succeed
in finding a way to use it!

-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C


Home | Main Index | Thread Index | Old Index