zfs-osx and äccénts

[Dave Cottlehuber]

Hey,

I'm a happy user of the new fork™ zfs-osx, with 1 smallish bug. Files
with accents (é, ü etc) are no longer accessible:

Π dch@akai % find * -type f
find: CV/Bundesanstalt_für_Geothermie.pdf: No such file or directory
find: wien/PersönlicheDaten-VC.xls: No such file or directory

Π dch@akai % cp CV/Bundesanstalt_fu<0308>r_Geothermie.pdf /tmp/cv.pdf
cp: CV/Bundesanstalt_für_Geothermie.pdf: No such file or directory

Finder refuses to show this at all of course. There are only a couple
of impacted filesystems BTW.

- How can I get these files back?
- What options does the filesystem or failing that the pool need to
"Just Work In Europe"?

NB this pool has a cherished history, it's an old maczfs 74.2 upgraded
to 74.3 and finally the new v5000 format, so it was not created with
the recommended options.

It would be awesome if there'e a way to get this working without
another zpool recreation.

A+
Dave

[ilov...@icloud.com]

Mac OS X basically expects you to use normalization=formD. However, this property can only be set at the time a data set is created. Therefore, I have create a branch for you that will allow you to break this rule. Please only use it while you are renaming your files. Then, revert to the master branch, create a new dataset with normalization=formD set at create time, and copy the files over.

The branch is called formdhack.

[Dave Cottlehuber]

On 18. November 2013 at 18:25:19, ilov...@icloud.com (ilov...@icloud.com) wrote:
>
> Mac OS X basically expects you to use normalization=formD. However,
> this
> property can only be set at the time a data set is created. Therefore,
> I
> have create a branch for you that will allow you to break this rule.
> Please
> only use it while you are renaming your files. Then, revert to
> the master
> branch, create a new dataset with normalization=formD set at
> create time,
> and copy the files over.
>
> The branch is called formdhack.

Thanks!!

Would it perhaps make sense to set this as the default then?

A+
D

[ilov...@icloud.com]

We could, though we've tried to maintain openzfs defaults across the board. The only exception I know of is the standard default block size for zvols is 8192, but on OS X 512 and 4096 are the only values that work properly with all of Apple's tools, so our default is 4096. Normalization might merit an exception, too, but so far we were only considering posting a message whenever a user runs zpool create or zfs create indicating what options the user will likely want to change from their defaults (e.g., atime=off, normalization=formD, and ashift=12). Of course, if the user did not do that, then the user would need to back-track and destroy the pool or dataset just created and try again.

On Monday, November 18, 2013 10:05:09 AM UTC-8, dch wrote:

On 18. November 2013 at 18:25:19, ilov...@icloud.com (ilov...@icloud.com) wrote:
>
> Mac OS X basically expects you to use normalization=formD. However,
> this
> property can only be set at the time a data set is created. Therefore,
> I

> have created a branch for you that will allow you to break this rule.

[Raoul Callaghan]

WD® Debuts World's First SSD+HDD Dual Drive

[Jason Belec]

Yeah but apparently you haven't been keeping up. WD drives have not had a good run under OS X and currently have some very serious issues under 10.9.x. I wish you well.

--

Jason Belec

Sent from my iPad

On Nov 25, 2013, at 7:20 PM, Raoul Callaghan <tan...@mac.com> wrote:

WD® Debuts World's First SSD+HDD Dual Drive

--
 
---
You received this message because you are subscribed to the Google Groups "zfs-macos" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zfs-macos+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Raoul Callaghan]

no no...

I rarely go near WD drives... My RocketRAID 2744 doesn't even recognise their firmware at all!

I've been using Seagate for quite some time now...

I was more curious on "how" ZFS deals with such drives... not whether I should buy/use them or not...

I'm just curious what ZFS would do (if anything) when the firmware on the drive decides to move some data from the SSD area to the spindle area... ;)

[Jason Belec]

Oh sorry, i just hate seeing people by stuff with such a history of heartbreak. ;)

Well technically they are just providing a Fusion drive that Apple announced over a year ago. Tests by several people posted on the web, one an exceptional ZFS wizard and tests by myself show they can work with caveats. Not necessarily good caveats.

These would have the same issues Apple's CoreServices tools and ZFS have, they both want total control and with good reason. ZFS is just better for true data integrity. The idea this kind of drive offers mating SSD and spinning-rust has significant advantages to 80% of users as they just throw crap onto their systems but want what they are using now to work fast. They should be more interested in data integrity, well if they wish to have a happy home life that is. ;)

Long run, I'm not sure this is a good way to go, but it is early. More testing with ZFS and perhaps how it works with various drives may be needed as well.

--

Jason Belec

Sent from my iPad

[Alex Bowden]

A little knowledge is such a dangerous thing.

If by "just a fusion drive" ,  you mean a single SSD bonded to a single HD by CoreStorage,  then that is nothing like ZFS

It doesn't claim to provide redundancy, any more than adding a SSD cache to a single disk pool would in ZFS.

But in ZFS the SSD would be a simple, and very well worthwhile cache,  whereas on the Apple Fusion drive, it is not a cache.  It is an extension to the storage.  But the system actively migrates the most used data to the SSD.

The exceptional ZFS wizard accidentally fails to note that the caveats, not necessarily good,  also apply to ZFS if you are using a single SSD cache an a single HD pool.

Personally I am using a CoreStorage Fusion Drive built from fusing together a pair of mirrored 512G SSDs with a 12 TB  Raid 5 HD array (both seen by the Mac as single drives,  or CoreStorage wont do the migration trick).

Would the data be safer on a Sun running Solaris and ZFS with a Raid5 ZFS pool with SSD caching?   Certainly.  Would it be faster?   I doubt it.

Would the data be safer on a Mac running a Beta version of an 3rd party ZFS port.     Forget it.

Anyway,  I want a native Mac file system.  A standard recovery partition. And bootability.   All with 100% compatibility with MacOS.

I've got that.  

Have you?

[Jason Belec]

So apparently Alex has the perfect setup. And believes HFS+ is good enough. Many people agree. Enjoy. 

--

Jason Belec

Sent from my iPad

[Philip Robar]

On Mon, Nov 25, 2013 at 7:54 PM, Jason Belec <jason...@belecmartin.com> wrote:

Yeah but apparently you haven't been keeping up. WD drives have not had a good run under OS X and currently have some very serious issues under 10.9.x. I wish you well.

My reading of the reports is that Mavericks has exposed a defect in WD's software and that the problem is not with WD's hardware or OS X.

I'd be interested in seeing statistically valid evidence that WD hard drives in general have historically had problems under OS X that they don't have in other environments.

Phil

[Jason Belec]

Well for me, of 50 WD drives utilized over the last 5 years, every single drive has failed catastrophically. I no longer bother with them, and swap any I come across with new clients immediately. I see about 5% failure for Seagate, about 8% for Hitachi drives still in play. Now perhaps my clients and I are just lucky or excessively heavy users day to day. I know some Windows folk who seem to enjoy some success with WD and it does seem to be a combination of OS and hardware that is successful. If your finding them good for your application then no worries. But a simple google search will provide a rather amazing number of issues with WD and Mac hardware running OS X but it could all be paid advertising.

--

Jason Belec

Sent from my iPad