xfs
[Top] [All Lists]

Re: Extended attributes limit in Linux

To: Jeff Liu <jeff.liu@xxxxxxxxxx>
Subject: Re: Extended attributes limit in Linux
From: Sun_Blood <sblood@xxxxxxxxx>
Date: Sun, 2 Feb 2014 16:31:33 +0100
Cc: Vyacheslav Dubeyko <slava@xxxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Ck83SE3r1/KJrTnnOs/clcshl5OkrnM6VOQOsA2nPdM=; b=vMFjuSMKHV6D95DT2qfu4lR/XSbMkLorT3Dm9ym7ZrqfDdZuqx4iGb40ky3tKggtDS nZRISDGPCZKyDSQMvwqfgjhKgu+7wupFRh4OyQKFX2G39hP2/avN65WOZh6UbHYznP81 K4AY8ILS68sY+BCfgzpog+WUO2LtkkgTdErGQU0cpug3WfI9oKT3XWPmtJcV4dTgNVfD 5yQBaQ3MoWPDcYnyOLiIVaKI0Dt7KHQeJSI2ai/3UQx1XZ+KroAolknbkKyBA2cBhOZ3 0b5rlfFck28TEX9BZZGR+okqg+FJjtAFWMmAns6NHawY2hQKyYamu5h7b1LLI0gt2yVB a0iQ==
In-reply-to: <52EE62AD.4030509@xxxxxxxxxx>
References: <CAMN6oR=a0G6O-3CVVkTwhYKavJTa543U3MLezCM8KW1ASZcPnA@xxxxxxxxxxxxxx> <52EB64DC.4020603@xxxxxxxxxx> <1391165083.4275.7.camel@ubuntu> <52EB960D.607@xxxxxxxxxx> <1391172723.4275.11.camel@ubuntu> <52EBA783.1080801@xxxxxxxxxx> <1391178074.4275.19.camel@ubuntu> <52EBB431.50301@xxxxxxxxxx> <6C94A326-DADE-4A32-97F6-AE84E9F57777@xxxxxxxxx> <1D87A7C9-988F-4F61-A577-67300DAF2554@xxxxxxxxxxx> <14FE2575-4C84-43B8-9992-F91ABE2B6F26@xxxxxxxxx> <52EE6069.7090905@xxxxxxxxxx> <52EE62AD.4030509@xxxxxxxxxx>

On 2 feb 2014, at 16:22, Jeff Liu <jeff.liu@xxxxxxxxxx> wrote:


On 02/02 2014 23:12 PM, Jeff Liu wrote:

On 02/02 2014 22:33 PM, Sun_Blood wrote:
<snip>
FYI, Example of output from one of the failing files. First from OS X
and then same file after failed copy to XFS.

OS X Maverik:
file: "/Users/username/Pictures/iPhoto
Library/Database/apdb/BigBlobs.apdb"
type: "\0\0\0\0"
creator: "\0\0\0\0"
attributes: avbstclinmedz
created: 01/25/2014 11:43:17
modified: 01/28/2014 20:02:46


Ubunutu 
getfattr: Removing leading '/' from absolute path names
# file: srv/nas/home/apple_bak_rsync/username/Pictures/iPhoto
Library/Database/BigBlobs.apdb
user.com.apple.quarantine="0006;52e39545;iPhoto;”


Sorry, but I don't quite follow your thought. What do you show by this
output?
What do you mean? Could you describe in more details?

Thanks,
Vyacheslav Dubeyko.

Sorry late reply. The output is just to show what happen after I
transfer a file from OS X to XFS that has EA bigger then 64k(I think).
When I try for example to rsync this file from OS X to Linux XFS I get
this error:
rsync: rsync_xal_set:
lsetxattr(""/srv/nas/home/apple_bak_rsync/xxxxxx/Pictures/iPhoto
Library/Database/BigBlobs.apdb"","user.com.apple.FinderInfo") failed:
Operation not permitted (1)

But also rsync can give this error.
rsync: rsync_xal_set:
lsetxattr(""/srv/danne/extern2/1000_EXT/2013/2013-03-05/IMG_6872-Edit.tif"","user.com.apple.ResourceFork")
failed: Argument list too long (7)

Is this 2 errors related?

Those errors are unrelated IMO, the first one is due to the permission rules but
I'm not sure the root cause, the second one is occurred as the EA value is larger
than 64K I guess.


I will make a bug report for rsync also that it should not try to copy
files with EA bigger then the destination can handle. But it would be
great if XFS could handle this files and be fully compatible with OS X
backups.

64K size is not limited by XFS directly, it is limited by VFS setxattr syscall.
IOWs, EA set operation is not yet get into XFS when "Argument list too long" error
is returned, so I think you would ran into the same error on other file systems
which are support 64K EA value size as well.

To be more precise, larger EA set operation would not works via setxattr(2) on Linux
regardless of the underlying file systems :).

Correct I did a quick test on ext4 and got the same fault.


Thanks,
-Jeff

So to be able to support this type of EA that OS X produce we need a change in the Linux kernel? Because XFS does handle it and is not the problem here.
<Prev in Thread] Current Thread [Next in Thread>