All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <boaz@plexistor.com>
To: "Björn JACKE" <bj@sernet.de>
Cc: Trond Myklebust <trond.myklebust@primarydata.com>,
	Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>
Subject: Re: size limit of extended attributes
Date: Thu, 30 Apr 2015 19:56:52 +0300	[thread overview]
Message-ID: <55425ED4.3090207@plexistor.com> (raw)
In-Reply-To: <E1YnqzW-001ZF7-46@intern.SerNet.DE>

On 04/30/2015 07:06 PM, Björn JACKE wrote:
> On 2015-04-30 at 17:46 +0300 Boaz Harrosh sent off:
>> The hacks need not be so ugly and they can be well documented and poblished
>> as a public STD.
>> 	./foo-with-streams (With xatters info)
>> 	./.foo-with-streams.__STREAMES__/ (backpointer xattrs-info)
>> 	./.foo-with-streams.__STREAMES__/SA
>> 	./.foo-with-streams.__STREAMES__/SB
>> 	...
>>   And some special mod bits on the .foo-with-streams.__STREAMES__ directory
>>
>> The smb read-dir parser removes those hidden directories
> 
> any hack like this would mean that for long file names which are close NAME_MAX
> this will not work. Yes, such long file names are being used.
>

Solvable use the infamous ....xxxx~1 encoding solution for the dirs

> Apart from the
> fact that the meta data is detached from the file, which also makes this
> workaround quite sub-optimal. Still the only real solution I see would be
> bigger EA sizes. I was hoping that this would be not a big challenge for the
> Linux kernel.
> 

Again you are ignoring my point. If the FS would like to (easily) keep these
xattrs for you, you have a POSIX API problem. You will need an alternate API
to be able to read/write these big xattrs in chunks.

It might be possible to make that 64K say 2M but you need a CONST-MAX size.
with current API, is there a number that will satisfy you?

> Björn
> 

Cheers
Boaz

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2015-04-30 16:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-30 11:33 size limit of extended attributes Björn JACKE
2015-04-30 12:38 ` Trond Myklebust
2015-04-30 13:57   ` Björn JACKE
2015-04-30 14:35     ` Theodore Ts'o
2015-04-30 14:46     ` Boaz Harrosh
2015-04-30 16:06       ` Björn JACKE
2015-04-30 16:56         ` Boaz Harrosh [this message]
2015-05-05 13:34           ` Björn JACKE
2015-05-01 15:43     ` Dave Chinner
2015-05-05 13:38       ` Björn JACKE
2015-05-05 15:43         ` Jan Kara
2015-05-06  1:31           ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55425ED4.3090207@plexistor.com \
    --to=boaz@plexistor.com \
    --cc=bj@sernet.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=trond.myklebust@primarydata.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.