As I mentioned in a former post viewtopic.php?f=26&t=3642 I had problems with xattr=on.
Cause of the vast amount of „on_delete_queue“ entries I decided to transform my datasets from xattr=on (dir) to xattr=sa.
Created new datasets with xattr=sa and copied the data with „rsync -XAa“.
Everything was fine, deleting, snapshotting, creating, copying from files without „on_delete_queue“ entries.
Out of curiosity, I looked at a pdf that I read with Skim.app. Skim is a nice tool to highlight text in a pdf and conveniently having all those parts together in a sidebar and I can easily print them or save them in a file. I wondered if skim saves the comments in the pdf or xattr?
It does so in xattr, so there are a lot of them (about 150) cause I highlighted so many parts.
- Code: Select all
-rw-r--r--@ 1 arne staff 16745387 21 Jul 2017 Re-Awaken_the_Giant_Within_Highres.pdf
net_sourceforge_skim-app_926CF362-9D34-4BE0-8009-8F8183834F0D-7 2048
net_sourceforge_skim-app_926CF362-9D34-4BE0-8009-8F8183834F0D-61 2048
net_sourceforge_skim-app_926CF362-9D34-4BE0-8009-8F8183834F0D-16 2048
net_sourceforge_skim-app_96C1FFDB-1746-4974-A391-6CB3B3AC3012-5 2048
net_sourceforge_skim-app_926CF362-9D34-4BE0-8009-8F8183834F0D-85 2048
net_sourceforge_skim-app_926CF362-9D34-4BE0-8009-8F8183834F0D-24 2048
net_sourceforge_skim-app_926CF362-9D34-4BE0-8009-8F8183834F0D-53 2048
net_sourceforge_skim-app_926CF362-9D34-4BE0-8009-8F8183834F0D-101 2048
…
Nice. But…
This file lies on an external pool which has xattr=on.
I created a test dataset „zfs-extern/arne/testsa“ with an additional „zfs snapshot zfs-extern/arne/testsa@test“.
When I tried to copy the file per drag and drop with Finder onto the dataset with xattr=sa the copy process starts but stops half way and the file is not copied at all.
A „zfs diff“ shows a lot of „on_delete_queue“ entries.
Per cp or rsync, it will copy the xattr in „<xattr>“ directory although the dataset has xattr=sa.(?)
- Code: Select all
M /Users/arne/testsa/
+ /Users/arne/testsa/Re-Awaken_the_Giant_Within_Highres.pdf
+ /Users/arne/testsa/Re-Awaken_the_Giant_Within_Highres.pdf/<xattrdir>/net_sourceforge_skim-app_926CF362-9D34-4BE0-8009-8F8183834F0D-82
+ /Users/arne/testsa/Re-Awaken_the_Giant_Within_Highres.pdf/<xattrdir>
+ /Users/arne/testsa/Re-Awaken_the_Giant_Within_Highres.pdf/<xattrdir>/net_sourceforge_skim-app_96C1FFDB-1746-4974-A391-6CB3B3AC3012-8
+ /Users/arne/testsa/Re-Awaken_the_Giant_Within_Highres.pdf/<xattrdir>/net_sourceforge_skim-app_926CF362-9D34-4BE0-8009-8F8183834F0D-0
+ /Users/arne/testsa/Re-Awaken_the_Giant_Within_Highres.pdf/<xattrdir>/net_sourceforge_skim-app_926CF362-9D34-4BE0-8009-8F8183834F0D-86
+ /Users/arne/testsa/Re-Awaken_the_Giant_Within_Highres.pdf/<xattrdir>/net_sourceforge_skim-app_926CF362-9D34-4BE0-8009-8F8183834F0D-68
+ /Users/arne/testsa/Re-Awaken_the_Giant_Within_Highres.pdf/<xattrdir>/net_sourceforge_skim-app_96C1FFDB-1746-4974-A391-6CB3B3AC3012-6
+ /Users/arne/testsa/Re-Awaken_the_Giant_Within_Highres.pdf/<xattrdir>/net_sourceforge_skim-app_926CF362-9D34-4BE0-8009-8F8183834F0D-15
…
Loading it in skim there are all highlights present.
Deleting per Finder or rm, there are a lot of „on_delete_queue“ entries. The „<xattr>/…“ I think. I guess that’s also the reason for those entries caused by the unsuccessful drag and drop copy with Finder.
I thought that 2.1.0 might handle it correctly.
So I changed to 2.1.0:
But it is worse than with 1.9.4.
With finder the file is copied, but not with all xattr, so that there are no notes visible in the pdf opened with skim.
Copying with rsync shows a lot of errors, stating on the attributes from skim: „… the current attribute … is not found (error 93)“.
I worried if there are errors in the xattr of the files in my production datasets which I copied from the old datasets with xattr=on(dir) to ones with xattr=sa before.
I tested it by copying a directory with rsync and it shocked me. rsync says that there are a lot of files where the attribute „com.apple.finderinfo 32“ is empty (0). And by looking into those files with „xattr -l“ they are indeed empty.
And shocking again that in the original datasets with xattr=on there are a lot of files with empty com.apple.finderinfo.
So I turned back to 1.9.4, again.
There are no files with empty „com.apple.finderinfo“.
Copying with rsync shows no problems with the files of the changed xattr property (in contrast to 2.1.0).
rsync and cp are copying the skim file, and the notes are again viewable in skim (as mentioned above).
And when I copy it with finder, the file is not copied. So it is as before with 1.9.4. Fine.
Strange though, when I copy the file first to my home directory (hfs+) per drag&drop it is copied and I than can copy it per drag&drop to the test directory with xattr=sa.
I tried changing some properties (com.apple.mimikhfs, dnodesize, com.apple.browse, ...) but nothing changes the problem with copying a skim file from a dataset with xattr=on to one with sa.
I almost loosed the faith in zfs, cause I was scared that all xattr where screwed with 2.1.0.
But it seems that only 2.1.0 has this severe problems.
With 1.9.4 I only have the problem with the one file from skim. I tested with other (normal, non Skim) files but those worked well. And I didn’t find one which has so many xattr like the one above.
And there is this strange writing of the xattr to directories instead of system-attributes although „xattr=sa“ is set. Or is it cause there are so many xattr and they are all 2048 byte big?
It now feels a little spooky to me using zfs. I make regular scrubs to be sure that there are no errors.
But there seems something wrong with this xattr property. I am not really certain anymore that zfs handles my files correctly, especially those with xattr.
Has anybody experienced this, too? Or am I the only one?
Should I avoid xattr at all and set xattr=off? But what about those programs that need ext. attributes?