From: nscott@aconex.com
To: Eric Sandeen <sandeen@sandeen.net>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH, RFC] - remove mounpoint UUID code
Date: Wed, 12 Mar 2008 07:09:56 +1100 (EST) [thread overview]
Message-ID: <34665.192.168.3.1.1205266196.squirrel@mail.aconex.com> (raw)
In-Reply-To: <47D5DE13.8030902@sandeen.net>
> Nathan Scott wrote:
>
>
> (hope you didn't too much mind my quoting you in this thread) ;)
(hope you didn't mind too much my dissing your cleanup) :)
>> Since effectively all versions of XFS support this feature ondisk,
>> including complete support in recovery, it would be better IMO to
>> leave it in for someone to implement/experiment with the syscall
>> and auto-mounting userspace support. That would then require no
>> new feature bits, mkfs/repair changes, etc. There is effectively
>> zero cost to leaving it there - and non-zero cost in removing it,
>> if our seriously bad regression-via-cleanup history is anything
>> to go by ... :|
>
> the only cost to leaving it is having another instance of "ok now what
> the heck is THIS?!" ... death by a thousand cuts of xfs complexity. But
> yeah, removing it has some risk too.
So, document it and move on. It would be a fun little project to go and
experiment with this code a bit. It amounts to a trivial amount of code
at the end of the day, and theres certainly nothing "complex" about it.
>> It would be really unfortunate to remove this, and then find that
>> it was useful to someone (who didn't know about it at this time).
>> OTOH, if there is definately never ever any chance this can ever
>> be useful, then it should indeed be removed. :)
>
> Well I'm not hung up about it. If anyone thinks it'll be useful, I'm
> not bothered by leaving it as is. So, Nathan, what are your plans for
> this code? *grin*
I don't have any immediate plans. I can imagine it could be used to
stitch parts of the namespace together in a filesystem that supports
multiple devices (in a chunkfs kinda way) ... or maybe more simply
just an in-filesystem auto-mounter. *shrug*. But its there, the tools
support it (once again, I didn't see a userspace patch - hohum), so I
would vote for leaving it in its current form so some enterprising,
constructive young coder can try to make something useful from it
at some point. :)
cheers.
next prev parent reply other threads:[~2008-03-11 20:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-08 4:00 [PATCH, RFC] - remove mounpoint UUID code Eric Sandeen
2008-03-08 4:31 ` Ian Costello
2008-03-08 4:33 ` Eric Sandeen
2008-03-08 4:40 ` Ian Costello
2008-03-08 4:59 ` Eric Sandeen
2008-03-08 11:54 ` Christoph Hellwig
2008-03-11 0:44 ` Nathan Scott
2008-03-11 1:19 ` Eric Sandeen
2008-03-11 20:09 ` nscott [this message]
2008-03-12 7:22 ` Christoph Hellwig
2008-07-08 3:09 ` [PATCH, RFC] - remove mountpoint " Eric Sandeen
2008-07-25 2:22 ` [PATCH, RFC] - remove mounpoint " Niv Sardi
2008-07-25 3:11 ` Eric Sandeen
2008-07-25 5:12 ` Niv Sardi
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=34665.192.168.3.1.1205266196.squirrel@mail.aconex.com \
--to=nscott@aconex.com \
--cc=sandeen@sandeen.net \
--cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox