From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 From: =?ISO-8859-1?Q?Rub=E9n_Berenguel?= Date: Fri, 7 Mar 2014 09:44:27 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11c3e70a2be4f004f400443d Subject: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c50293be-ead8-11e9-9d60-3106f5b1d025 --001a11c3e70a2be4f004f400443d Content-Type: text/plain; charset=ISO-8859-1 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 --001a11c3e70a2be4f004f400443d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,=A0

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

The part about USB is just because it happen= s 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=A0
--001a11c3e70a2be4f004f400443d-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: Sergey Zhilkin Date: Fri, 7 Mar 2014 12:54:52 +0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=047d7bd752a863c38f04f40069a8 Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c510123c-ead8-11e9-9d60-3106f5b1d025 --047d7bd752a863c38f04f40069a8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=C3=A9n Berenguel : > 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, dossr= v > can't do it (already tried). > > Thanks, > > Ruben > --=20 =D0=A1 =D0=BD=D0=B0=D0=B8=D0=BB=D1=83=D1=87=D1=88=D0=B8=D0=BC=D0=B8 =D0=BF= =D0=BE=D0=B6=D0=B5=D0=BB=D0=B0=D0=BD=D0=B8=D1=8F=D0=BC=D0=B8 =D0=96=D0=B8=D0=BB=D0=BA=D0=B8=D0=BD =D0=A1=D0=B5=D1=80=D0=B3=D0=B5=D0=B9 With best regards Zhilkin Sergey --047d7bd752a863c38f04f40069a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello !=C2=A0

Plan9 can't mount HFS= or HFS+ filesystems (no fileservers :) ) but you can use USB disk by forma= tting 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=C3=A9n Berenguel <ruben@mostlymaths.net>= ;:
Hi all,=C2=A0

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=C2=A0



--
=D0=A1 =D0= =BD=D0=B0=D0=B8=D0=BB=D1=83=D1=87=D1=88=D0=B8=D0=BC=D0=B8 =D0=BF=D0=BE=D0= =B6=D0=B5=D0=BB=D0=B0=D0=BD=D0=B8=D1=8F=D0=BC=D0=B8
=D0=96=D0=B8=D0=BB= =D0=BA=D0=B8=D0=BD =D0=A1=D0=B5=D1=80=D0=B3=D0=B5=D0=B9
With best regard= s
Zhilkin Sergey
--047d7bd752a863c38f04f40069a8-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Fri, 7 Mar 2014 10:00:35 +0100 Message-ID: From: Gorka Guardiola To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c514f644-ead8-11e9-9d60-3106f5b1d025 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 wrote: > Hello ! > > Plan9 can't mount HFS or HFS+ filesystems (no fileservers :) ) but you ca= n > 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 unsopport= ed. > Please read prep(8) for how to lebel and format disks. :) > > > 2014-03-07 12:44 GMT+04:00 Rub=C3=A9n Berenguel : > >> 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, doss= rv >> can't do it (already tried). >> >> Thanks, >> >> Ruben > > > > > -- > =D0=A1 =D0=BD=D0=B0=D0=B8=D0=BB=D1=83=D1=87=D1=88=D0=B8=D0=BC=D0=B8 =D0= =BF=D0=BE=D0=B6=D0=B5=D0=BB=D0=B0=D0=BD=D0=B8=D1=8F=D0=BC=D0=B8 > =D0=96=D0=B8=D0=BB=D0=BA=D0=B8=D0=BD =D0=A1=D0=B5=D1=80=D0=B3=D0=B5=D0=B9 > With best regards > Zhilkin Sergey --=20 - curiosity sKilled the cat From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1283) From: David Swasey In-Reply-To: Date: Fri, 7 Mar 2014 10:47:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c5194528-ead8-11e9-9d60-3106f5b1d025 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 >=20 > On Fri, Mar 7, 2014 at 9:54 AM, Sergey Zhilkin = wrote: >> Hello ! >>=20 >> 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. :) >>=20 >>=20 >> 2014-03-07 12:44 GMT+04:00 Rub=C3=A9n Berenguel = : >>=20 >>> Hi all, >>>=20 >>> can Plan9 access a USB disk formatted with HFS plus (i.e. the Mac OS >>> Extended (& journaled) file system? >>>=20 >>> 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). >>>=20 >>> Thanks, >>>=20 >>> Ruben >>=20 >>=20 >>=20 >>=20 >> -- >> =D0=A1 =D0=BD=D0=B0=D0=B8=D0=BB=D1=83=D1=87=D1=88=D0=B8=D0=BC=D0=B8 = =D0=BF=D0=BE=D0=B6=D0=B5=D0=BB=D0=B0=D0=BD=D0=B8=D1=8F=D0=BC=D0=B8 >> =D0=96=D0=B8=D0=BB=D0=BA=D0=B8=D0=BD =D0=A1=D0=B5=D1=80=D0=B3=D0=B5=D0=B9= >> With best regards >> Zhilkin Sergey >=20 >=20 >=20 > --=20 > - curiosity sKilled the cat >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Fri, 7 Mar 2014 11:49:44 -0500 To: 9fans@9fans.net Message-ID: <656c0f615d55ce5f418af43c59d01fe1@mikro.quanstro.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c5318318-ead8-11e9-9d60-3106f5b1d025 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 From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <656c0f615d55ce5f418af43c59d01fe1@mikro.quanstro.net> References: <656c0f615d55ce5f418af43c59d01fe1@mikro.quanstro.net> From: =?ISO-8859-1?Q?Rub=E9n_Berenguel?= Date: Sat, 8 Mar 2014 13:30:44 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a113a9c02493f9304f4178b0d Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c539864e-ead8-11e9-9d60-3106f5b1d025 --001a113a9c02493f9304f4178b0d Content-Type: text/plain; charset=ISO-8859-1 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 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 > > --001a113a9c02493f9304f4178b0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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 commit= ment I wanted to give to this, which was only the moderately convenient rem= ote access. I know how to use disk/fdisk and disk/prep, more or less, to cr= eate partitions compatible with P9, this is not a problem.

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

I have caved in and just used a (far smaller) FA= T 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 underst= and, 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 b= e 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,=A0<= /div>

Ruben<= /div>

On Fri, Mar = 7, 2014 at 5:49 PM, erik quanstrom <quanstro@quanstro.net> wrote:
On Fri Mar =A07 04:01:31 EST= 2014, paurea@gmail.com wrote:
> This would probably make for a nice GSoC project (even if, for the pur= poses 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/HF= SPLUS/tn1150.html#BTrees

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

- erik


--001a113a9c02493f9304f4178b0d-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sat, 8 Mar 2014 07:35:12 -0500 To: 9fans@9fans.net Message-ID: In-Reply-To: References: <656c0f615d55ce5f418af43c59d01fe1@mikro.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c53dc10a-ead8-11e9-9d60-3106f5b1d025 > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <656c0f615d55ce5f418af43c59d01fe1@mikro.quanstro.net> From: =?ISO-8859-1?Q?Rub=E9n_Berenguel?= Date: Sat, 8 Mar 2014 13:59:51 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11c11ed868976104f417f39c Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c541fee6-ead8-11e9-9d60-3106f5b1d025 --001a11c11ed868976104f417f39c Content-Type: text/plain; charset=ISO-8859-1 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 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 > > --001a11c11ed868976104f417f39c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the quick reply. Where is exactly the proper po= int to consider it as "started on boot"? I really don't know = how the Plan9 boot process follows along (I guess "something" loa= ds /lib/profile which in turn loads /rc/bin/termrc, but I'm not even su= re 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 <qua= nstro@quanstro.net> wrote:
> A mildly related questi= on, 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<= br> > machine with the current username, in its own namespace, and as such a= n
> external drive (say, usbfat: mounted) won't be there (since the mo= untpoint
> won't be in the remotely connected namespace.) Is there any workar= ound 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. =A0easiest way to do this is t= o start it on
boot and add to /lib/namespace.

- erik


--001a11c11ed868976104f417f39c-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sat, 8 Mar 2014 08:03:11 -0500 To: 9fans@9fans.net Message-ID: <5ede24014831aca7fb8032baa529a2f8@mikro.quanstro.net> In-Reply-To: References: <656c0f615d55ce5f418af43c59d01fe1@mikro.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c5475e36-ead8-11e9-9d60-3106f5b1d025 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 From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <5ede24014831aca7fb8032baa529a2f8@mikro.quanstro.net> References: <656c0f615d55ce5f418af43c59d01fe1@mikro.quanstro.net> <5ede24014831aca7fb8032baa529a2f8@mikro.quanstro.net> From: =?ISO-8859-1?Q?Rub=E9n_Berenguel?= Date: Sat, 8 Mar 2014 15:08:45 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11c3e70ace0de304f418e9b3 Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c555e0c8-ead8-11e9-9d60-3106f5b1d025 --001a11c3e70ace0de304f418e9b3 Content-Type: text/plain; charset=ISO-8859-1 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 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 > > --001a11c3e70ace0de304f418e9b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sorry to be bothersome again, but still can't figure i= t out. I need /srv/dos available in /lib/namespace, so I can mount the exte= rnal 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 bes= ide 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 =A08 08:01:20 EST= 2014, ruben@mostlymaths.net w= rote:

> Thanks for the quick reply. Where is exactly the proper point to consi= der
> it as "started on boot"? I really don't know how the Pla= n9 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 i= gnore errors.
so as long as the relevant srv files are available before newns() is called= ,
you can access them.

- erik


--001a11c3e70ace0de304f418e9b3-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sat, 8 Mar 2014 09:18:24 -0500 To: 9fans@9fans.net Message-ID: In-Reply-To: References: <656c0f615d55ce5f418af43c59d01fe1@mikro.quanstro.net> <5ede24014831aca7fb8032baa529a2f8@mikro.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c55ba300-ead8-11e9-9d60-3106f5b1d025 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Sickel Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <035D548B-43D9-4FC6-B127-7297A3356C1C@corpus-callosum.com> Date: Sat, 8 Mar 2014 09:16:21 -0600 References: In-Reply-To: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c569fef0-ead8-11e9-9d60-3106f5b1d025 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://p= lan9.bell-labs.com/magic/man2html/4/u9fs)? Or drawterm from a Mac with the d= rive connected? Or running Inferno hosted on the Mac and exporting the volu= me? Any of these would make the HFSX file system available to your Plan 9 host. -jas From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <035D548B-43D9-4FC6-B127-7297A3356C1C@corpus-callosum.com> References: <035D548B-43D9-4FC6-B127-7297A3356C1C@corpus-callosum.com> From: =?ISO-8859-1?Q?Rub=E9n_Berenguel?= Date: Sat, 8 Mar 2014 18:53:57 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a113a9c0223d1da04f41c0f90 Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c56ea52c-ead8-11e9-9d60-3106f5b1d025 --001a113a9c0223d1da04f41c0f90 Content-Type: text/plain; charset=ISO-8859-1 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 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 > > > --001a113a9c0223d1da04f41c0f90 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The thing is, I don't want access to HFS+ from my Plan= 9 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.c= om> wrote:
I agree with Gorka, this would be a good GSoC project.

But there are other ways to mount the device. =A0Have you tried u9fs (h= ttp://plan9.bell-labs.com/magic/man2html/4/u9fs)? =A0Or drawterm from a= Mac with the drive connected? =A0Or 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



--001a113a9c0223d1da04f41c0f90-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sat, 8 Mar 2014 12:58:24 -0500 To: 9fans@9fans.net Message-ID: In-Reply-To: References: <035D548B-43D9-4FC6-B127-7297A3356C1C@corpus-callosum.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c5733024-ead8-11e9-9d60-3106f5b1d025 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. =CE=B8fs(4) http://www.9atom.org/magic/man2html/4/%CE%B8fs is designed for this. it serves nfs as well as 9p directly. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <035D548B-43D9-4FC6-B127-7297A3356C1C@corpus-callosum.com> From: =?ISO-8859-1?Q?Rub=E9n_Berenguel?= Date: Sat, 8 Mar 2014 19:11:26 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=089e0158a9e4ae9a4c04f41c4d88 Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c629ce1a-ead8-11e9-9d60-3106f5b1d025 --089e0158a9e4ae9a4c04f41c4d88 Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable I don't seem to have =E8fs, which is weird (the Raspberry Pi distribution i= s 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 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. > > =E8fs(4) http://www.9atom.org/magic/man2html/4/%CE%B8fs > is designed for this. it serves nfs as well as 9p directly. > > - erik > > --089e0158a9e4ae9a4c04f41c4d88 Content-Type: text/html; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable
I don't seem to have=A0=E8fs, which is weird (the Raspberry Pi distri= bution 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 =A08 12:55:25 EST= 2014, ruben@mostlymaths.net w= rote:

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

=E8fs(4) =A0http://www.9atom.org/magic/man2html/4/%CE%B8fs
is designed for this. =A0it serves nfs as well as 9p directly.

- erik


--089e0158a9e4ae9a4c04f41c4d88-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: "Steve Simon" Date: Sat, 8 Mar 2014 18:27:00 +0000 To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c6381308-ead8-11e9-9d60-3106f5b1d025 > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: =?ISO-8859-1?Q?Rub=E9n_Berenguel?= Date: Sun, 9 Mar 2014 09:39:28 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=089e01536d4a17ba9204f4286e1b Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c64391ce-ead8-11e9-9d60-3106f5b1d025 --089e01536d4a17ba9204f4286e1b Content-Type: text/plain; charset=ISO-8859-1 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 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 > > --089e01536d4a17ba9204f4286e1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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.=A0<= div>
I finally managed to exportfs the drive, I'm not sur= e if due to a combination of things in /lib/namespace or the -t flag in lis= ten1 did the trick, or the combination of the two. I was happy for around 3= 0 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> w= rote:
> I want my
> Plan9 host to serve a HFS+ drive.

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

-Steve


--089e01536d4a17ba9204f4286e1b-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sun, 9 Mar 2014 12:42:07 -0400 To: 9fans@9fans.net Message-ID: In-Reply-To: References: <035D548B-43D9-4FC6-B127-7297A3356C1C@corpus-callosum.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c6cb47c2-ead8-11e9-9d60-3106f5b1d025 On Sat Mar 8 13:12:40 EST 2014, ruben@mostlymaths.net wrote: > I don't seem to have =CE=B8fs, which is weird (the Raspberry Pi distrib= ution 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Sickel Content-Type: multipart/alternative; boundary="Apple-Mail=_67F0EEEF-A828-470D-98DB-7AB4A951E038" Message-Id: <6B81A986-6489-46E0-87C5-A0ABC6B21208@corpus-callosum.com> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Date: Sun, 9 Mar 2014 12:52:10 -0500 References: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c6d45808-ead8-11e9-9d60-3106f5b1d025 --Apple-Mail=_67F0EEEF-A828-470D-98DB-7AB4A951E038 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Rub=E9n,=20 For better, or worse, nothing really serves HFS+ these days. Apple=92s = transitioning from AFP to SMB2 when sharing files. I can=92t say I=92m = disappointed that AFP is finally going away. Until someone writes an HFSX fs device support you won=92t be able to = mount a drive formatted under OSX. You could mount a FAT device, within = reason. I=92ve had trouble getting Plan 9=92s NFS server to serve up bits that = OSX client can actually use. Someone else=92s milage may vary. Same = goes for CIFS. Now if you=92re trying to exportfs to a Mac there are several levels of = pain you can go through: 1) mac9p =97 ask fsb for more details (or google mac9p and find his hg = repo or the github fork) 2) cifs =97 read the aquarela man page 3) 9pfuse =97 I=92ve not tested this with recent fuse versions 4) nfs =97 this shouldn=92t 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=E9n Berenguel = 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.=20 >=20 > 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. >=20 >=20 > On Sat, Mar 8, 2014 at 7:27 PM, Steve Simon = wrote: > > I want my > > Plan9 host to serve a HFS+ drive. >=20 > 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. >=20 > -Steve >=20 >=20 --Apple-Mail=_67F0EEEF-A828-470D-98DB-7AB4A951E038 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Rub=E9n, 

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

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

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

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

 1) mac9p =97 ask fsb for more = details (or google mac9p and find his hg repo or the github = fork)
 2) cifs =97 read the aquarela man = page
 3) 9pfuse  =97 I=92ve not tested this with = recent fuse versions
 4) nfs =97 this shouldn=92t 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=E9n 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



= --Apple-Mail=_67F0EEEF-A828-470D-98DB-7AB4A951E038-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <6B81A986-6489-46E0-87C5-A0ABC6B21208@corpus-callosum.com> References: <6B81A986-6489-46E0-87C5-A0ABC6B21208@corpus-callosum.com> From: =?ISO-8859-1?Q?Rub=E9n_Berenguel?= Date: Sun, 9 Mar 2014 19:05:46 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a113a5a9e4b51c204f43057ed Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c6da42fe-ead8-11e9-9d60-3106f5b1d025 --001a113a5a9e4b51c204f43057ed Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jeff, thanks: On Sun, Mar 9, 2014 at 6:52 PM, Jeff Sickel wrote= : > Rub=E9n, > > 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 pai= n > you can go through: > > 1) mac9p -- ask fsb for more details (or google mac9p and find his hg re= po > 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=E9n Berenguel wro= te: > > 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 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 >> >> > > --001a113a5a9e4b51c204f43057ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jeff, thanks:


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

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’v= e had trouble getting Plan 9’s NFS server to serve up bits that OSX c= lient can actually use.  Someone else’s milage may vary.  S= ame goes for CIFS.

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

&nbs= p;1) mac9p — ask fsb for more details (or google mac9p and find his h= g repo or the github fork)

Hmmm... The use at your own risk doe= sn'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
<= /blockquote>

Did yesterday, wasn't convinced and thought nfs would be bet= ter...
 
 3) 9pfuse  — I’ve not tested this with recent f= use versions

The pipe essential= ly breaks after ~30 seconds with the latest version of osxfuse, unknown rea= son (no matter how many d's I add to 9import). I can read the remote dr= ive during this time, access and create files. But when it dies, it dies &q= uot;hard" so I need to remove the tmp/ns.file in Mac OS, eject the fus= e volume, etc. Painful, and anyway, not that useful.
 
 4) nfs — this shouldn’t be painful, bu= t it is

That's the impression I got from the m= an pages :(
 

But I usually find that connecting to my Plan 9 cpu ser= vers through drawterm or Inferno tends to be the best bridge|least pain (th= ough 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, everyt= hing works as expected. But I wanted a solution that was relatively straigh= tforward 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, s= ince this was a good "reasoned" way to justify an always on devic= e with Plan9... Now I think it will be a device with Raspbian or Plan9 depe= nding 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=E9n Berenguel <ruben@mostlymaths.net> wrote:=

Thanks Steve. In any c= ase, 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 se= conds, 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> w= rote:
> I want my
> Plan9 host to serve a HFS+ drive.

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

-Steve




--001a113a5a9e4b51c204f43057ed-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4e12279bf7a74df2fef43eeab8e7bfa4@bellsouth.net> To: 9fans@9fans.net Date: Sun, 9 Mar 2014 22:01:43 -0400 From: blstuart@bellsouth.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c70d8146-ead8-11e9-9d60-3106f5b1d025 > =CE=B8fs(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/=CE=B8fs. 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, =CE=B8fs 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sun, 9 Mar 2014 22:08:04 -0400 To: 9fans@9fans.net Message-ID: <2294484cb1126f047aef616de74886f1@mikro.quanstro.net> In-Reply-To: <4e12279bf7a74df2fef43eeab8e7bfa4@bellsouth.net> References: <4e12279bf7a74df2fef43eeab8e7bfa4@bellsouth.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c7144e4a-ead8-11e9-9d60-3106f5b1d025 > - Taking a snapshot is an O(1) operation most interestingly, that is a property of #=E2=84=99, which is not direct= ly tied to =CE=B8fs. so you could, with arrangements, snapshot any other file system. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <63b66fddcab7a5f6d6738cd1ac0c1229@bellsouth.net> To: 9fans@9fans.net Date: Sun, 9 Mar 2014 22:19:34 -0400 From: blstuart@bellsouth.net In-Reply-To: <2294484cb1126f047aef616de74886f1@mikro.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c7236cb8-ead8-11e9-9d60-3106f5b1d025 >> - Taking a snapshot is an O(1) operation >=20 > most interestingly, that is a property of #=E2=84=99, which is not dire= ctly > tied to =CE=B8fs. so you could, with arrangements, snapshot any other > file system. That's correct. #=E2=84=99 doesn't depend on =CE=B8fs at all. =CE=B8fs = can be used without #=E2=84=99, but it does have some provisions for using #=E2=84=99= to provide a /n/dump/yyyy/mmdd name space. With similar provision, one could use #=E2=84=99 to create a snapshotted kfs that was similarly efficient. BLS