[9fans] Accessing Mac OS Extended drives

[9fans] Accessing Mac OS Extended drives

[Rubén Berenguel]

[-- Attachment #1: Type: text/plain, Size: 317 bytes --]

Hi all,

can Plan9 access a USB disk formatted with HFS plus (i.e. the Mac OS
Extended (& journaled) file system?

The part about USB is just because it happens to be an USB drive, but
basically I don't know how to mount the /dev/sdD.D/data. Of course, dossrv
can't do it (already tried).

Thanks,

Ruben

[-- Attachment #2: Type: text/html, Size: 441 bytes --]

Re: [9fans] Accessing Mac OS Extended drives

[Sergey Zhilkin]

[-- Attachment #1: Type: text/plain, Size: 839 bytes --]

Hello !

Plan9 can't mount HFS or HFS+ filesystems (no fileservers :) ) but you can
use USB disk by formatting it to a supported filesystem (fossil(4),
kfs(4)). I think, that your Mac USB disk is labaled as UUID, and UUID is
unsopported. Please read prep(8) for how to lebel and format disks. :)


2014-03-07 12:44 GMT+04:00 Rubén Berenguel <ruben@mostlymaths.net>:

> Hi all,
>
> can Plan9 access a USB disk formatted with HFS plus (i.e. the Mac OS
> Extended (& journaled) file system?
>
> The part about USB is just because it happens to be an USB drive, but
> basically I don't know how to mount the /dev/sdD.D/data. Of course, dossrv
> can't do it (already tried).
>
> Thanks,
>
> Ruben
>



-- 
С наилучшими пожеланиями
Жилкин Сергей
With best regards
Zhilkin Sergey

[-- Attachment #2: Type: text/html, Size: 1306 bytes --]

Re: [9fans] Accessing Mac OS Extended drives

[Gorka Guardiola]

This would probably make for a nice GSoC project (even if, for the purposes of
the project is a read only, without all the bells and whistles,
version of HFS+). It is documented for example here:
http://dubeiko.com/development/FileSystems/HFSPLUS/tn1150.html#BTrees

On Fri, Mar 7, 2014 at 9:54 AM, Sergey Zhilkin <szhilkin@gmail.com> wrote:
> Hello !
>
> Plan9 can't mount HFS or HFS+ filesystems (no fileservers :) ) but you can
> use USB disk by formatting it to a supported filesystem (fossil(4), kfs(4)).
> I think, that your Mac USB disk is labaled as UUID, and UUID is unsopported.
> Please read prep(8) for how to lebel and format disks. :)
>
>
> 2014-03-07 12:44 GMT+04:00 Rubén Berenguel <ruben@mostlymaths.net>:
>
>> Hi all,
>>
>> can Plan9 access a USB disk formatted with HFS plus (i.e. the Mac OS
>> Extended (& journaled) file system?
>>
>> The part about USB is just because it happens to be an USB drive, but
>> basically I don't know how to mount the /dev/sdD.D/data. Of course, dossrv
>> can't do it (already tried).
>>
>> Thanks,
>>
>> Ruben
>
>
>
>
> --
> С наилучшими пожеланиями
> Жилкин Сергей
> With best regards
> Zhilkin Sergey



-- 
- curiosity sKilled the cat

Re: [9fans] Accessing Mac OS Extended drives

[David Swasey]

Plan9port's libdiskfs might suffice for reading that USB drive.
It supports hfs, read-only.

-dave

On Mar 7, 2014, at 10:00, Gorka Guardiola wrote:

> This would probably make for a nice GSoC project (even if, for the purposes of
> the project is a read only, without all the bells and whistles,
> version of HFS+). It is documented for example here:
> http://dubeiko.com/development/FileSystems/HFSPLUS/tn1150.html#BTrees
> 
> On Fri, Mar 7, 2014 at 9:54 AM, Sergey Zhilkin <szhilkin@gmail.com> wrote:
>> Hello !
>> 
>> Plan9 can't mount HFS or HFS+ filesystems (no fileservers :) ) but you can
>> use USB disk by formatting it to a supported filesystem (fossil(4), kfs(4)).
>> I think, that your Mac USB disk is labaled as UUID, and UUID is unsopported.
>> Please read prep(8) for how to lebel and format disks. :)
>> 
>> 
>> 2014-03-07 12:44 GMT+04:00 Rubén Berenguel <ruben@mostlymaths.net>:
>> 
>>> Hi all,
>>> 
>>> can Plan9 access a USB disk formatted with HFS plus (i.e. the Mac OS
>>> Extended (& journaled) file system?
>>> 
>>> The part about USB is just because it happens to be an USB drive, but
>>> basically I don't know how to mount the /dev/sdD.D/data. Of course, dossrv
>>> can't do it (already tried).
>>> 
>>> Thanks,
>>> 
>>> Ruben
>> 
>> 
>> 
>> 
>> --
>> С наилучшими пожеланиями
>> Жилкин Сергей
>> With best regards
>> Zhilkin Sergey
> 
> 
> 
> -- 
> - curiosity sKilled the cat
> 

Re: [9fans] Accessing Mac OS Extended drives

[erik quanstrom]

On Fri Mar  7 04:01:31 EST 2014, paurea@gmail.com wrote:
> This would probably make for a nice GSoC project (even if, for the purposes of
> the project is a read only, without all the bells and whistles,
> version of HFS+). It is documented for example here:
> http://dubeiko.com/development/FileSystems/HFSPLUS/tn1150.html#BTrees

keep in mind that hfs+ support will be a little difficult without gpt
partitions.  so gpt support might be even more useful.

- erik

Re: [9fans] Accessing Mac OS Extended drives

[Rubén Berenguel]

[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]

Thanks all for the prompt replies. I add a few answers:

@Sergey: The point is using an existing HFS+ with ~500 GB of data. Moving
all the data and reformatting is way beyond the time commitment I wanted to
give to this, which was only the moderately convenient remote access. I
know how to use disk/fdisk and disk/prep, more or less, to create
partitions compatible with P9, this is not a problem.

@David: Using Plan9ports is a weird way to manage a HFS+ formatted device:
linux and Mac OS have HFS+ support, BSD has partial support, all built-ins.

I have caved in and just used a (far smaller) FAT device.

A mildly related question, though (I'm getting a little lost among
namespaces):

How can I (I guess it's possible?) exportfs an external drive? As far as I
understand, 9import (or in general, import) will connect to my remote
machine with the current username, in its own namespace, and as such an
external drive (say, usbfat: mounted) won't be there (since the mountpoint
won't be in the remotely connected namespace.) Is there any workaround for
this? I can drawterm and cp, but I'd like to simplify it and just 9import
via fuse and move files when needed.

Thanks,

Ruben

On Fri, Mar 7, 2014 at 5:49 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> On Fri Mar  7 04:01:31 EST 2014, paurea@gmail.com wrote:
> > This would probably make for a nice GSoC project (even if, for the
> purposes of
> > the project is a read only, without all the bells and whistles,
> > version of HFS+). It is documented for example here:
> > http://dubeiko.com/development/FileSystems/HFSPLUS/tn1150.html#BTrees
>
> keep in mind that hfs+ support will be a little difficult without gpt
> partitions.  so gpt support might be even more useful.
>
> - erik
>
>

[-- Attachment #2: Type: text/html, Size: 2759 bytes --]

Re: [9fans] Accessing Mac OS Extended drives

[erik quanstrom]

> A mildly related question, though (I'm getting a little lost among
> namespaces):
>
> How can I (I guess it's possible?) exportfs an external drive? As far as I
> understand, 9import (or in general, import) will connect to my remote
> machine with the current username, in its own namespace, and as such an
> external drive (say, usbfat: mounted) won't be there (since the mountpoint
> won't be in the remotely connected namespace.) Is there any workaround for
> this? I can drawterm and cp, but I'd like to simplify it and just 9import
> via fuse and move files when needed.

needs to be in export's namespace.  easiest way to do this is to start it on
boot and add to /lib/namespace.

- erik

Re: [9fans] Accessing Mac OS Extended drives

[Rubén Berenguel]

[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

Thanks for the quick reply. Where is exactly the proper point to consider
it as "started on boot"? I really don't know how the Plan9 boot process
follows along (I guess "something" loads /lib/profile which in turn loads
/rc/bin/termrc, but I'm not even sure about this ordering), and so far the
documentation for this is a little... too twisty.

Ruben


On Sat, Mar 8, 2014 at 1:35 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> > A mildly related question, though (I'm getting a little lost among
> > namespaces):
> >
> > How can I (I guess it's possible?) exportfs an external drive? As far as
> I
> > understand, 9import (or in general, import) will connect to my remote
> > machine with the current username, in its own namespace, and as such an
> > external drive (say, usbfat: mounted) won't be there (since the
> mountpoint
> > won't be in the remotely connected namespace.) Is there any workaround
> for
> > this? I can drawterm and cp, but I'd like to simplify it and just 9import
> > via fuse and move files when needed.
>
> needs to be in export's namespace.  easiest way to do this is to start it
> on
> boot and add to /lib/namespace.
>
> - erik
>
>

[-- Attachment #2: Type: text/html, Size: 1700 bytes --]

Re: [9fans] Accessing Mac OS Extended drives

[erik quanstrom]

On Sat Mar  8 08:01:20 EST 2014, ruben@mostlymaths.net wrote:

> Thanks for the quick reply. Where is exactly the proper point to consider
> it as "started on boot"? I really don't know how the Plan9 boot process
> follows along (I guess "something" loads /lib/profile which in turn loads
> /rc/bin/termrc, but I'm not even sure about this ordering), and so far the
> documentation for this is a little... too twisty.

it doesn't really have to be started at boot time, newns() will ignore errors.
so as long as the relevant srv files are available before newns() is called,
you can access them.

- erik

Re: [9fans] Accessing Mac OS Extended drives

[Rubén Berenguel]

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]

Sorry to be bothersome again, but still can't figure it out. I need
/srv/dos available in /lib/namespace, so I can mount the external drive
before anything else is done on the system, but to do so I need to execute
dossrv, and in a namespace file I can't execute anything beside bind/mount
and related commands (at least according to namespace(6))

Ruben


On Sat, Mar 8, 2014 at 2:03 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> On Sat Mar  8 08:01:20 EST 2014, ruben@mostlymaths.net wrote:
>
> > Thanks for the quick reply. Where is exactly the proper point to consider
> > it as "started on boot"? I really don't know how the Plan9 boot process
> > follows along (I guess "something" loads /lib/profile which in turn loads
> > /rc/bin/termrc, but I'm not even sure about this ordering), and so far
> the
> > documentation for this is a little... too twisty.
>
> it doesn't really have to be started at boot time, newns() will ignore
> errors.
> so as long as the relevant srv files are available before newns() is
> called,
> you can access them.
>
> - erik
>
>

[-- Attachment #2: Type: text/html, Size: 1619 bytes --]

Re: [9fans] Accessing Mac OS Extended drives

[erik quanstrom]

On Sat Mar  8 09:10:24 EST 2014, ruben@mostlymaths.net wrote:

> Sorry to be bothersome again, but still can't figure it out. I need
> /srv/dos available in /lib/namespace, so I can mount the external drive
> before anything else is done on the system, but to do so I need to execute
> dossrv, and in a namespace file I can't execute anything beside bind/mount
> and related commands (at least according to namespace(6))

there would be a line similar to in /lib/namespace

	mount /srv/thing /n/thing

if /srv/thing is available when the connection is made, then
/n/thing is mounted.

/lib/namespace is not a shell script; the directives available
are documented in namespace(6).

- erik

Re: [9fans] Accessing Mac OS Extended drives

[Jeff Sickel]

I agree with Gorka, this would be a good GSoC project.

But there are other ways to mount the device.  Have you tried u9fs (http://plan9.bell-labs.com/magic/man2html/4/u9fs)?  Or drawterm from a Mac with the drive connected?  Or running Inferno hosted on the Mac and exporting the volume?

Any of these would make the HFSX file system available to your Plan 9 host.

-jas

Re: [9fans] Accessing Mac OS Extended drives

[Rubén Berenguel]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

The thing is, I don't want access to HFS+ from my Plan9 host. I want my
Plan9 host to serve a HFS+ drive. Access is required, but it's not the end
goal.


On Sat, Mar 8, 2014 at 4:16 PM, Jeff Sickel <jas@corpus-callosum.com> wrote:

> I agree with Gorka, this would be a good GSoC project.
>
> But there are other ways to mount the device.  Have you tried u9fs (
> http://plan9.bell-labs.com/magic/man2html/4/u9fs)?  Or drawterm from a
> Mac with the drive connected?  Or running Inferno hosted on the Mac and
> exporting the volume?
>
> Any of these would make the HFSX file system available to your Plan 9 host.
>
> -jas
>
>
>

[-- Attachment #2: Type: text/html, Size: 1052 bytes --]

Re: [9fans] Accessing Mac OS Extended drives

[erik quanstrom]

On Sat Mar  8 12:55:25 EST 2014, ruben@mostlymaths.net wrote:

> The thing is, I don't want access to HFS+ from my Plan9 host. I want my
> Plan9 host to serve a HFS+ drive. Access is required, but it's not the end
> goal.

θfs(4) 	http://www.9atom.org/magic/man2html/4/%CE%B8fs
is designed for this.  it serves nfs as well as 9p directly.

- erik

Re: [9fans] Accessing Mac OS Extended drives

[Rubén Berenguel]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

I don't seem to have θfs, which is weird (the Raspberry Pi distribution is
9atom, isn't it?.) At least, its source is not in sys/src/cmd. I pulled
changes 3 or 4 days ago.


On Sat, Mar 8, 2014 at 6:58 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> On Sat Mar  8 12:55:25 EST 2014, ruben@mostlymaths.net wrote:
>
> > The thing is, I don't want access to HFS+ from my Plan9 host. I want my
> > Plan9 host to serve a HFS+ drive. Access is required, but it's not the
> end
> > goal.
>
> θfs(4)  http://www.9atom.org/magic/man2html/4/%CE%B8fs
> is designed for this.  it serves nfs as well as 9p directly.
>
> - erik
>
>

[-- Attachment #2: Type: text/html, Size: 1254 bytes --]

Re: [9fans] Accessing Mac OS Extended drives

[Steve Simon]

> I want my
> Plan9 host to serve a HFS+ drive.

If you want to serve files (rather than  a block device) from plan9 to
a mac then plan9 has an nfs server and, two cifs servers available.

-Steve

Re: [9fans] Accessing Mac OS Extended drives

[Rubén Berenguel]

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

Thanks Steve. In any case, I can't serve HFS+ serving files because P9
can't access them. But I could serve a FAT device.

I finally managed to exportfs the drive, I'm not sure if due to a
combination of things in /lib/namespace or the -t flag in listen1 did the
trick, or the combination of the two. I was happy for around 30 seconds,
which is the time 9pfuse (9import) took to issue a "broken pipe" on my
terminal, killing the connection to my remote disk. Pretty fed up of
setting up a remote drive by now.


On Sat, Mar 8, 2014 at 7:27 PM, Steve Simon <steve@quintile.net> wrote:

> > I want my
> > Plan9 host to serve a HFS+ drive.
>
> If you want to serve files (rather than  a block device) from plan9 to
> a mac then plan9 has an nfs server and, two cifs servers available.
>
> -Steve
>
>

[-- Attachment #2: Type: text/html, Size: 1256 bytes --]

Re: [9fans] Accessing Mac OS Extended drives

[erik quanstrom]

On Sat Mar  8 13:12:40 EST 2014, ruben@mostlymaths.net wrote:

> I don't seem to have θfs, which is weird (the Raspberry Pi distribution is
> 9atom, isn't it?.) At least, its source is not in sys/src/cmd. I pulled
> changes 3 or 4 days ago.

the rpi distribution is not 9atom.

- erik

Re: [9fans] Accessing Mac OS Extended drives

[Jeff Sickel]

[-- Attachment #1: Type: text/plain, Size: 1942 bytes --]

Rubén, 

For better, or worse, nothing really serves HFS+ these days.  Apple’s transitioning from AFP to SMB2 when sharing files.  I can’t say I’m disappointed that AFP is finally going away.

Until someone writes an HFSX fs device support you won’t be able to mount a drive formatted under OSX.  You could mount a FAT device, within reason.

I’ve had trouble getting Plan 9’s NFS server to serve up bits that OSX client can actually use.  Someone else’s milage may vary.  Same goes for CIFS.

Now if you’re trying to exportfs to a Mac there are several levels of pain you can go through:

 1) mac9p — ask fsb for more details (or google mac9p and find his hg repo or the github fork)
 2) cifs — read the aquarela man page
 3) 9pfuse  — I’ve not tested this with recent fuse versions
 4) nfs — this shouldn’t be painful, but it is

But I usually find that connecting to my Plan 9 cpu servers through drawterm or Inferno tends to be the best bridge|least pain (though mac9p tends to be a really good option).

-jas

On Mar 9, 2014, at 3:39 AM, Rubén Berenguel <ruben@mostlymaths.net> wrote:

> Thanks Steve. In any case, I can't serve HFS+ serving files because P9 can't access them. But I could serve a FAT device. 
> 
> I finally managed to exportfs the drive, I'm not sure if due to a combination of things in /lib/namespace or the -t flag in listen1 did the trick, or the combination of the two. I was happy for around 30 seconds, which is the time 9pfuse (9import) took to issue a "broken pipe" on my terminal, killing the connection to my remote disk. Pretty fed up of setting up a remote drive by now.
> 
> 
> On Sat, Mar 8, 2014 at 7:27 PM, Steve Simon <steve@quintile.net> wrote:
> > I want my
> > Plan9 host to serve a HFS+ drive.
> 
> If you want to serve files (rather than  a block device) from plan9 to
> a mac then plan9 has an nfs server and, two cifs servers available.
> 
> -Steve
> 
> 


[-- Attachment #2: Type: text/html, Size: 2979 bytes --]

Re: [9fans] Accessing Mac OS Extended drives

[Rubén Berenguel]

[-- Attachment #1: Type: text/plain, Size: 3563 bytes --]

Hi Jeff, thanks:


On Sun, Mar 9, 2014 at 6:52 PM, Jeff Sickel <jas@corpus-callosum.com> wrote:

> Rubén,
>
> For better, or worse, nothing really serves HFS+ these days.  Apple's
> transitioning from AFP to SMB2 when sharing files.  I can't say I'm
> disappointed that AFP is finally going away.
>
> Until someone writes an HFSX fs device support you won't be able to mount
> a drive formatted under OSX.  You could mount a FAT device, within reason.
>
> I've had trouble getting Plan 9's NFS server to serve up bits that OSX
> client can actually use.  Someone else's milage may vary.  Same goes for
> CIFS.
>
> Now if you're trying to exportfs to a Mac there are several levels of pain
> you can go through:
>
>  1) mac9p -- ask fsb for more details (or google mac9p and find his hg repo
> or the github fork)
>

Hmmm... The use at your own risk doesn't sound really encouraging... I'm
wary of kexts, even installing fuse from brew was a little over the edge.
If it wasn't because I have used sshfs in the past and found it almost
indispensable in most cases, I would have skipped it.


>  2) cifs -- read the aquarela man page
>

Did yesterday, wasn't convinced and thought nfs would be better...


>  3) 9pfuse  -- I've not tested this with recent fuse versions
>

The pipe essentially breaks after ~30 seconds with the latest version of
osxfuse, unknown reason (no matter how many d's I add to 9import). I can
read the remote drive during this time, access and create files. But when
it dies, it dies "hard" so I need to remove the tmp/ns.file in Mac OS,
eject the fuse volume, etc. Painful, and anyway, not that useful.


>  4) nfs -- this shouldn't be painful, but it is
>

That's the impression I got from the man pages :(


>
> But I usually find that connecting to my Plan 9 cpu servers through
> drawterm or Inferno tends to be the best bridge|least pain (though mac9p
> tends to be a really good option).
>

Drawterm works like a charm (some day I will compile and try the iOS
version...), and I can use it with cp without any problems, everything
works as expected. But I wanted a solution that was relatively
straightforward so that we (me and my SO) could access the drive without
needing (relatively) complicated steps.

I don't know what I'll do from this point on, since this was a good
"reasoned" way to justify an always on device with Plan9... Now I think it
will be a device with Raspbian or Plan9 depending on what I want to do...
And it will probably mean Raspbian more often than not (so I can use APL.)

Ruben


>
> -jas
>
> On Mar 9, 2014, at 3:39 AM, Rubén Berenguel <ruben@mostlymaths.net> wrote:
>
> Thanks Steve. In any case, I can't serve HFS+ serving files because P9
> can't access them. But I could serve a FAT device.
>
> I finally managed to exportfs the drive, I'm not sure if due to a
> combination of things in /lib/namespace or the -t flag in listen1 did the
> trick, or the combination of the two. I was happy for around 30 seconds,
> which is the time 9pfuse (9import) took to issue a "broken pipe" on my
> terminal, killing the connection to my remote disk. Pretty fed up of
> setting up a remote drive by now.
>
>
> On Sat, Mar 8, 2014 at 7:27 PM, Steve Simon <steve@quintile.net> wrote:
>
>> > I want my
>> > Plan9 host to serve a HFS+ drive.
>>
>> If you want to serve files (rather than  a block device) from plan9 to
>> a mac then plan9 has an nfs server and, two cifs servers available.
>>
>> -Steve
>>
>>
>
>

[-- Attachment #2: Type: text/html, Size: 5792 bytes --]

Re: [9fans] Accessing Mac OS Extended drives

[blstuart]

> θfs(4) 	http://www.9atom.org/magic/man2html/4/%CE%B8fs
> is designed for this.  it serves nfs as well as 9p directly.

I've been meaning to send out an announcement for a while, but this
has been a pretty hectic week with the SIGCSE conference.  Thanks to
Coraid and Brantely Coile, I am releasing an early version of the file
system I've been using for several months now.  It's actually the 7th
in a series named by letters from the Greek alphabet.  Some of it's
general characteristics include:

- Runs in user-space on a CPU server or terminal
- When used with the snap device, supports snapshots that are
compatible with the existing file history utilities
- Taking a snapshot is an O(1) operation
- Serves both 9P and NFSv3, including symbolic links and device nodes
- NFS support has been tested with MacOS, Linux, and FreeBSD
- Serves block storage via AoE
- Serves object storage via an experimental object extension to AoE
- There are rough ports to UNIXish systems via P9P
- With suitable changes to boot/local.c, can be used for a file server
root

Some of the downsides are:

- No lock daemon for NFS
- There's an odd error when unmounting from FreeBSD
- Rather un-parsimonious in its space usage: relatively big block
size, no compression, no de-duping (so far)
- No significant work on performance yet
- Very little in the way of documentation

It's been my primary file server since about October.  So as you might
guess, most of the development has taken place on it.  Naturally,
quite a few bugs have been found and sorted out, but I can't make any
guarantees about stability or prime-time readiness.

The snapshot kernel device is available in contrib/blstuart/snap, and
the file system is in contrib/blstuart/θfs.  It's also included in
9atom, and we're working on getting it included in the installer as an
alternative to kfs and fossil-venti.

If you want to use it outside of 9atom, you'll need a modification to
lib9p that's in P9P and 9atom, but as I recall, not in the Labs'
distribution.  In particular, θfs expects the start and end function
pointers in the Srv structure.

Feel free to use it if you have any interest.  I'll be glad to help
try to sort out any issues you run into.

Thanks,
BLS

Re: [9fans] Accessing Mac OS Extended drives

[erik quanstrom]

> - Taking a snapshot is an O(1) operation

most interestingly, that is a property of #ℙ, which is not directly
tied to θfs.  so you could, with arrangements, snapshot any other
file system.

- erik

Re: [9fans] Accessing Mac OS Extended drives

[blstuart]

>> - Taking a snapshot is an O(1) operation
> 
> most interestingly, that is a property of #ℙ, which is not directly
> tied to θfs.  so you could, with arrangements, snapshot any other
> file system.

That's correct.  #ℙ doesn't depend on θfs at all.  θfs can be used
without #ℙ, but it does have some provisions for using #ℙ to provide a
/n/dump/yyyy/mmdd name space.  With similar provision, one could use
#ℙ to create a snapshotted kfs that was similarly efficient.

BLS