From: "NeilBrown" <neilb@suse.de>
To: "Josef 'Jeff' Sipek" <jeffpc@josefsipek.net>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
xfs@oss.sgi.com, "Adam Schrotenboer" <adam@m2000.com>,
"Jesper Juhl" <jesper.juhl@gmail.com>,
"Trond Myklebust" <trond.myklebust@netapp.com>,
linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org,
"Thomas Daniel" <tdaniel@m2000.com>,
"Frederic Revenu" <frevenu@m2000.com>,
"Jeff Doan" <jdoan@m2000.com>
Subject: Re: [opensuse] nfs_update_inode: inode X mode changed, Y to Z
Date: Wed, 26 Mar 2008 10:09:00 +1100 (EST) [thread overview]
Message-ID: <45922.192.168.1.70.1206486540.squirrel@neil.brown.name> (raw)
In-Reply-To: <20080325221321.GC20257@josefsipek.net>
On Wed, March 26, 2008 9:13 am, Josef 'Jeff' Sipek wrote:
> On Wed, Mar 26, 2008 at 08:38:22AM +1100, NeilBrown wrote:
> ...
>> However you still need to do something about the generation number. It
>> must be set to something.
>
> Right.
>
>> When you allocate an inode that doesn't currently exist on the device,
>> you obviously cannot increment the old value and use that.
>
> Makes sense.
>
>> However you can do a lot better than always using 0.
>
> I looked at the code (xfs_ialloc.c:xfs_ialloc_ag_alloc)
>
> 290 /*
> 291 * Set initial values for the inodes in this buffer.
> 292 */
> 293 xfs_biozero(fbuf, 0, ninodes <<
> args.mp->m_sb.sb_inodelog);
> 294 for (i = 0; i < ninodes; i++) {
> 295 free = XFS_MAKE_IPTR(args.mp, fbuf, i);
> 296 free->di_core.di_magic =
> cpu_to_be16(XFS_DINODE_MAGIC);
> 297 free->di_core.di_version = version;
> 298 free->di_next_unlinked =
> cpu_to_be32(NULLAGINO);
> 299 xfs_ialloc_log_di(tp, fbuf, i,
> 300 XFS_DI_CORE_BITS |
> XFS_DI_NEXT_UNLINKED);
> 301 }
>
> xfs_biozero(...) turns into a memset(buf, 0, len), and since the loop that
> follows doesn't change the generation number, it'll stay 0.
>
>> The simplest would be to generate a 'random' number (get_random_bytes).
>> Slightly better would be to generate a random number at boot time
>> and use that, incrementing it each time it is used to set the
>> generation number for an inode.
>
> I'm not familiar enough with NFS, do you want something that's
> monotonically
> increasing or do you just test for inequality? If it is inequality, why
> not
> just use something like the jiffies - that should be unique enough.
>
What we need is for the "filehandle" to be stable and unique.
By 'stable' I mean that every time I get the filehandle for a particular
file, I get the same string of bytes.
By 'uniqie' I mean that if I get two filehandles for two different
files, they must differ in at least one bit.
If a file is deleted and the inode is re-used for a new file, then the
old and new files are different and must have different file handles.
The filehandle is traditionally generated from the inode number and
a generation number, but the filesystem can actually do whatever it
likes. xfs does it with xfs_fs_encode_fh().
Certainly you could initialise the i_generation to jiffies in
xfs_ialloc_ag_alloc. That would be a suitable fix. get_random_bytes
might be better, but the difference probably wouldn't be noticeable.
NeilBrown
next prev parent reply other threads:[~2008-03-25 23:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <9a8748490803121513w285cd45rb6b26a3d842cac1b@mail.gmail.com>
[not found] ` <20080312221511.GC31632@fieldses.org>
[not found] ` <9a8748490803121516u36395872i70cc88b0439adc74@mail.gmail.com>
[not found] ` <18394.1501.991087.80264@notabene.brown>
[not found] ` <47DAEFD0.9020407@m2000.com>
[not found] ` <47E92F8E.7030504@m2000.com>
[not found] ` <20080325190943.GF2237@fieldses.org>
[not found] ` <32953.192.168.1.70.1206477121.squirrel@neil.brown.name>
[not found] ` <20080325212425.GA20257@josefsipek.net>
[not found] ` <34178.192.168.1.70.1206481102.squirrel@neil.brown.name>
2008-03-25 22:13 ` Josef 'Jeff' Sipek
2008-03-25 23:09 ` NeilBrown [this message]
2008-03-26 3:37 ` David Chinner
2008-03-26 5:02 ` David Chinner
2008-04-17 19:37 ` Adam Schrotenboer
[not found] <47C5EC81.6080004@m2000.com>
[not found] ` <47C71EC6.3050702@m2000.com>
[not found] ` <3AD71C5E-B45A-4BDB-8C94-73D62256BEBF@astro.wisc.edu>
2008-03-12 18:06 ` Adam Schrotenboer
[not found] <47CF0829.4020502@m2000.com>
[not found] ` <1204752463.5035.34.camel@heimdal.trondhjem.org>
[not found] ` <47CF157B.1010908@m2000.com>
[not found] ` <18383.24847.381754.517731@notabene.brown>
[not found] ` <47CF62C5.7000908@m2000.com>
[not found] ` <18384.50909.866848.966192@notabene.brown>
2008-03-07 5:55 ` Adam Schrotenboer
2008-03-12 17:55 ` Adam Schrotenboer
2008-03-12 18:08 ` Trond Myklebust
2008-03-12 18:16 ` Adam Schrotenboer
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=45922.192.168.1.70.1206486540.squirrel@neil.brown.name \
--to=neilb@suse.de \
--cc=adam@m2000.com \
--cc=bfields@fieldses.org \
--cc=frevenu@m2000.com \
--cc=jdoan@m2000.com \
--cc=jeffpc@josefsipek.net \
--cc=jesper.juhl@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=tdaniel@m2000.com \
--cc=trond.myklebust@netapp.com \
--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
all inboxes | Powered by JetHome®