From: "Victor Mataré" <dreck@vmsd.ath.cx>
To: linux-nfs@vger.kernel.org
Subject: numeric UIDs
Date: Tue, 3 Aug 2010 04:01:32 +0200 [thread overview]
Message-ID: <201008030401.33552.dreck@vmsd.ath.cx> (raw)
Hello,
I still hope I'm mistaken in assuming I have to go back to NFSv3 if I want to
skip NFSv4 UID mapping altogether and just use the numeric UIDs the way
they're stored on-disk. However if that's actually true, I'd like to try and
make a case for implementing an option to turn off UID mapping completely (or
at least for unknown UIDs). If this is already work in progress, just ignore
this mail.
Thing is, the forced UID mapping seems to make tasks like backing up data a
little inconvenient. You might want to preserve UIDs that are only known to
the client.
But when you copy an entire root filesystem, it becomes outright destructive,
because the rootfs will probably have several accounts that the server can't
be expected know. Just imagine a server that's used for maintenance (like
backing up and replacing hard drives) of random (foreign) systems. Idmapd will
map all unknown UIDs to a single value and thereby destroy that information.
I think I read somewhere that the Sun people already have a way of handling
this. Any chance Linux could do that, too?
Please excuse me if I'm barking up the wrong tree. If this has already been
discussed, I'd appreciate a pointer.
Thanks,
Victor
next reply other threads:[~2010-08-03 2:07 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-03 2:01 Victor Mataré [this message]
2010-08-03 16:43 ` numeric UIDs Jim Rees
2010-08-03 19:22 ` J. Bruce Fields
2010-08-03 21:49 ` Daniel.Muntz
2010-08-03 21:57 ` Jim Rees
2010-08-03 22:15 ` Trond Myklebust
2010-08-03 22:23 ` J. Bruce Fields
2010-08-03 22:31 ` Trond Myklebust
2010-08-03 22:42 ` J. Bruce Fields
2010-08-04 2:02 ` Trond Myklebust
2010-08-04 17:06 ` David Brodbeck
2010-08-04 18:30 ` Andy Adamson
2010-08-04 21:32 ` David Brodbeck
2010-08-11 23:06 ` Neil Brown
2010-08-12 13:20 ` Andy Adamson
2010-08-11 23:10 ` Neil Brown
2010-08-05 15:34 ` J. Bruce Fields
2010-08-11 23:22 ` Neil Brown
2010-08-13 14:43 ` Steve Dickson
2010-08-13 16:31 ` J. Bruce Fields
2010-08-13 17:30 ` Steve Dickson
[not found] ` <4C658146.90207-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2010-08-13 17:37 ` J. Bruce Fields
2010-08-13 18:43 ` Chuck Lever
2010-08-17 17:46 ` Tom Haynes
2010-08-17 18:18 ` J. Bruce Fields
2010-08-17 18:43 ` Tom Haynes
2010-08-17 18:49 ` J. Bruce Fields
2010-08-17 19:21 ` J. Bruce Fields
[not found] ` <4C6559FA.5070809-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2010-08-16 8:30 ` Neil Brown
2010-08-13 14:40 ` Steve Dickson
2010-08-03 19:22 ` J. Bruce Fields
2010-08-17 17:48 ` Tom Haynes
2010-08-17 18:24 ` J. Bruce Fields
2010-08-17 19:00 ` Tom Haynes
2010-08-17 20:08 ` David Brodbeck
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=201008030401.33552.dreck@vmsd.ath.cx \
--to=dreck@vmsd.ath.cx \
--cc=linux-nfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).