[git pull] vfs pile 2

Al Viro

unread,

Dec 17, 2009, 11:30:03 AM12/17/09

to

Misc bits and pieces, cleaning the table for scaling stuff...
Please, pull from
git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git/ master
in a few minutes (or directly from hera)

Al Viro (1):
dio: fix use-after-free

Christoph Hellwig (3):
fix up O_SYNC comments
fold do_sync_file_range into sys_sync_file_range
kill I_LOCK

Erez Zadok (2):
fsstack/ecryptfs: remove unused get_nlinks param to fsstack_copy_attr_all
VFS/fsstack: handle 32-bit smp + preempt + large files in fsstack_copy_inode_size

Jeff Layton (1):
vfs: remove extraneous NULL d_inode check from do_filp_open

Nick Piggin (2):
fs: anon_inodes implement dname
fs: no games with DCACHE_UNHASHED

Linus Torvalds

unread,

Dec 17, 2009, 11:40:03 AM12/17/09

to

On Thu, 17 Dec 2009, Al Viro wrote:
>
> Misc bits and pieces, cleaning the table for scaling stuff...
> Please, pull from
> git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git/ master
> in a few minutes (or directly from hera)

Btw, would you mind cleaning that repo up?

It has a few very annoying things, the first and foremost of which is that
HEAD points to some crazy branch (new-truncate).

So when you do "git pull" without mentioning the branch (which is the
normal behavior) and would expect to get your default thing (which was
also what you asked me to pull in your original pull request), you instead
get some totally inexplicable old random crud.

That's really unexpected for a bare repository. I spent some time looking
at the odd conflicts the other day when I pulled originally.

I suspect you just did a "scp -rp" or something to initially set it up,
which is why it contains some random branch - that just happened to be
your active branch at the time you did that setup.

(It also has FETCH_HEAD, index, COMMIT_EDITMSG etc - all things that don't
make sense in a bare repository)

Linus

Al Viro

unread,

Dec 17, 2009, 1:10:02 PM12/17/09

to

On Thu, Dec 17, 2009 at 08:39:14AM -0800, Linus Torvalds wrote:
>
>
> On Thu, 17 Dec 2009, Al Viro wrote:
> >
> > Misc bits and pieces, cleaning the table for scaling stuff...
> > Please, pull from
> > git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git/ master
> > in a few minutes (or directly from hera)
>
> Btw, would you mind cleaning that repo up?

Sure.

> That's really unexpected for a bare repository. I spent some time looking
> at the odd conflicts the other day when I pulled originally.
>
> I suspect you just did a "scp -rp" or something to initially set it up,
> which is why it contains some random branch - that just happened to be
> your active branch at the time you did that setup.

IIRC, it was _way_ back and done as git clone -l -s <your tree> vfs-2.6
followed by mv vfs-2.6/.git /pub/scm/...../vfs-2.6.git. So it probably
_isn't_ a proper bare repository in the first place.

OK... I've edited config a bit, set HEAD to ref: refs/heads/master and
tried to clean the things up. What I still don't understand is why the
hell does it have an apparently unkillable dangling commit that seems
to be yours, despite having alternates pointing to your tree. *And*
a bunch of loose objects sitting around and impossible to get rid of...

Linus Torvalds

unread,

Dec 17, 2009, 1:20:02 PM12/17/09

to

On Thu, 17 Dec 2009, Al Viro wrote:
>
> OK... I've edited config a bit, set HEAD to ref: refs/heads/master and
> tried to clean the things up. What I still don't understand is why the
> hell does it have an apparently unkillable dangling commit that seems
> to be yours, despite having alternates pointing to your tree. *And*
> a bunch of loose objects sitting around and impossible to get rid of...

Git is _very_ nervous about getting rid of old objects, because even if
they aren't reachable, you might recover them with "git fsck" etc. By
default there's something like a 2-month (or maybe just two weeks, I'm too
lazy to check) expiration logic for objects that are loose and
unreachable.

You can force git to get rid of those kinds of objects using

git prune --expire=now

or similar.

[ Btw, things that _look_ unreachable may also be reachable through the
reflog, which is not normally something you'd have in a bare repository
anyway, but since you created the bare repo by copying/moving a non-bare
one, you may well have reflog entries.

Doing

git reflog expire --all --expire=now

should get rid of them, but you could also decide to just do it all the
brute-force way with just "rm -rf logs" ]

Linus

Al Viro

unread,

Dec 17, 2009, 1:50:02 PM12/17/09

to

On Thu, Dec 17, 2009 at 10:16:08AM -0800, Linus Torvalds wrote:

> You can force git to get rid of those kinds of objects using
>
> git prune --expire=now
>
> or similar.
>
> [ Btw, things that _look_ unreachable may also be reachable through the
> reflog, which is not normally something you'd have in a bare repository
> anyway, but since you created the bare repo by copying/moving a non-bare
> one, you may well have reflog entries.
>
> Doing
>
> git reflog expire --all --expire=now
>
> should get rid of them, but you could also decide to just do it all the
> brute-force way with just "rm -rf logs" ]

reflog had been pruned already; still no effect. Moreover, after looking
through the loose objects, I've found several commits that are definitely
reachable from master and now from your tree as well. E.g.
objects/ea/ff8079d4f1016a12e34ab323737314f24127dd
is one of those - it's a commit and it's both in mainline *and* happens
to be tip of master. No questions about being unreachable and AFAICS
no reasons whatsoever to leave it as a loose object...

Linus Torvalds

unread,

Dec 17, 2009, 4:30:02 PM12/17/09

to

On Thu, 17 Dec 2009, Al Viro wrote:
>

> reflog had been pruned already; still no effect. Moreover, after looking
> through the loose objects, I've found several commits that are definitely
> reachable from master and now from your tree as well. E.g.
> objects/ea/ff8079d4f1016a12e34ab323737314f24127dd
> is one of those - it's a commit and it's both in mainline *and* happens
> to be tip of master. No questions about being unreachable and AFAICS
> no reasons whatsoever to leave it as a loose object...

If you want a maximal pack, use "git repack -Adl"

The default gc thing will stop when it hits stuff that has been packed
already, which can leave _older_ unpacked objects unpacked. And since my
own repo isn't always fully packed, and git will only remove local objects
if they are available as _packed_ objects in the reference tree (ie my
repo), you'll end up with that kind of situation.

I usually repack my tree a couple of times per release, no more often, so
you'll seldom see _perfect_ packing.

Linus

Al Viro

unread,

Dec 17, 2009, 4:50:02 PM12/17/09

to

On Thu, Dec 17, 2009 at 01:22:12PM -0800, Linus Torvalds wrote:
>
>
> On Thu, 17 Dec 2009, Al Viro wrote:
> >
> > reflog had been pruned already; still no effect. Moreover, after looking
> > through the loose objects, I've found several commits that are definitely
> > reachable from master and now from your tree as well. E.g.
> > objects/ea/ff8079d4f1016a12e34ab323737314f24127dd
> > is one of those - it's a commit and it's both in mainline *and* happens
> > to be tip of master. No questions about being unreachable and AFAICS
> > no reasons whatsoever to leave it as a loose object...
>
> If you want a maximal pack, use "git repack -Adl"

Still leaves the same bunch.

> The default gc thing will stop when it hits stuff that has been packed
> already, which can leave _older_ unpacked objects unpacked. And since my
> own repo isn't always fully packed, and git will only remove local objects
> if they are available as _packed_ objects in the reference tree (ie my
> repo), you'll end up with that kind of situation.

Yeah, but why aren't they put into local pack? They _are_ new and they
definitely are referenced. The newest in the repository, as the matter
of fact.

Odd...

Linus Torvalds

unread,

Dec 17, 2009, 5:00:02 PM12/17/09

to

On Thu, 17 Dec 2009, Al Viro wrote:
>
> Yeah, but why aren't they put into local pack? They _are_ new and they
> definitely are referenced. The newest in the repository, as the matter
> of fact.
>
> Odd...

Hmm. It seems to be the same objects that are unpacked in my repo. What
happens is probably that git doesn't want to pack them, because they are
available in the alternates, but then also doesn't want to prune them,
because they aren't available in a _pack_ in the alternate.

That does look like something we migth decide to want to change in git.
Maybe.

But I repacked my repo, just so that you can get your "no loose objects"
situation you want ;)

Linus