I'm still trying to find why I have fossil data twice the size of the
files served.
Since this is almost exactly (minus the MB of kerTeX) twice the size, I
wonder if fossil has, from the installation, still a recorded plan9.iso,
not visible when mounting main.
Since I have done an installation lo
have you already done something like
du -a | sort -nr | sed 20q
in the main tree?. (it may make sense to
remount /srv/boot someplace else to avoid device, etc.)
- erik
Summary of the previous episodes: after having reinstalled Plan9, with
almost only the vanilla distribution, du(1) announces 325 MB, while
fossil uses twice the place to store.
I suspected, since it was clearly almost precisely twice (minus some tmp
files and kerTeX), that the problem was the plan
How have you deleted the plan9.iso file?
If you have used rm(1) or fossilcons(4) remove, the blocks
should be properly unallocated from Fossil. But if you used
fossilcons(4) clri for example, you have to manually reclaim
the abandoned storage with clre and bfree, with the help of
fossil/flchk or f
> But the surprise is that it was _not_ hidden. It _was_ here under /dist
> ... but apparently not added to the summary made by du(1)? Does du(1)
> "know" that some dir are mount point taking (normally) no real space,
> and skipping them? Because this means one can add whatever files in
> there and
On Fri, Jan 13, 2012 at 08:59:32AM -0500, erik quanstrom wrote:
> > But the surprise is that it was _not_ hidden. It _was_ here under /dist
> > ... but apparently not added to the summary made by du(1)? Does du(1)
> > "know" that some dir are mount point taking (normally) no real space,
> > and ski
On Fri, Jan 13, 2012 at 02:59:52PM +0100, David du Colombier wrote:
> How have you deleted the plan9.iso file?
>
I have used in user space rm(1), and then on the console: check, since
it is said to reclaim the space. And it did.
I have now half the size of the previous one, and this matches the
> > i think your / has mounts and binds that are confusing du. you
> > need to remount your root file system someplace free of mounts
> > or binds on top, e.g.:
> >
> > ; mount /srv/boot /n/boot; cd /n/boot
> > ; du -s .>[2=]
> > 4049232 .
> > ; du -sh .>[2=]
> > 3.861649G
2012/1/11 :
>
> (1) For example, P9 code tends to use variable names like "i" and "j",
> where I would typically use self-documenting variable names like "row"
> and "col". Variable names like "row" and "col" are much easier to
> search for (i.e., with a right-click), too. Names like "i" and "j"
On Fri, Jan 13, 2012 at 09:47:25AM -0500, erik quanstrom wrote:
>
> please try what i suggested. i've shown that du -h works properly
> on my system.
>
Indeed, remounting yields the correct Mb result.
What I missed, is that the result of du(1) is not in bytes, but in
_kilobytes_ (since I know
> The mounts in my profile are the vanilla ones (the only customizations
> are for the network, the mouse, the keyboard). I do not play with the
> namespace.
>
> Have you an idea where to look to find what are the offending
> instructions? /boot(8)?
they're not offending! not all files in a typi
> The mounts in my profile are the vanilla ones (the only customizations
> are for the network, the mouse, the keyboard). I do not play with the
> namespace.
>
> Have you an idea where to look to find what are the offending
> instructions? /boot(8)?
It's probably simply because /root is a recursi
On Fri, Jan 13, 2012 at 11:16:11AM -0500, erik quanstrom wrote:
>
> they're not offending! not all files in a typical plan 9 namespace
> make sense to du. for example, if you're runing rio, it doesn't make
> sense to add that to the file total. also, if you have a disk in
> /dev/sdXX/data, that
> On a side note. When using mount(8) without arguments on a typical
> Unix, one can see what is mounted where. Is there some way to find the
> "organization" of the namespace on Plan9? (What is mount'ed and what
> is bind'ed?
ns(1)
--
David du Colombier
On Fri, Jan 13, 2012 at 05:17:34PM +0100, David du Colombier wrote:
> > The mounts in my profile are the vanilla ones (the only customizations
> > are for the network, the mouse, the keyboard). I do not play with the
> > namespace.
> >
> > Have you an idea where to look to find what are the offend
tlaro...@polynum.com writes:
> On a side note. When using mount(8) without arguments on a typical
> Unix, one can see what is mounted where. Is there some way to find the
> "organization" of the namespace on Plan9? (What is mount'ed and what
> is bind'ed?
Sure... ns(1) :-)
--
Vivien
The name space can contain loops. Du and a few others try to detect that,
using Qids, to avoid being annoying, but the loops are there.
Open (and chdir etc) do indeed record the name used to open the file, and
that helps
resolve the ".." problem (now done slightly differently from the paper, I
thin
On Fri, Jan 13, 2012 at 05:44:36PM +0100, Vivien MOREAU wrote:
> tlaro...@polynum.com writes:
>
> > On a side note. When using mount(8) without arguments on a typical
> > Unix, one can see what is mounted where. Is there some way to find the
> > "organization" of the namespace on Plan9? (What is m
On Fri, Jan 13, 2012 at 05:41:01PM +0100, tlaro...@polynum.com wrote:
> >
> > See /lib/namespace.
>
> Yes, but reading "Getting Dot-Dot right" by Rob Pike, I thought that the
> solution was to have, underneath, one uniq pathname for a file. Date(1)
> can format UTC; whatever the user presentation
On Fri, Jan 13, 2012 at 04:50:34PM +, Charles Forsyth wrote:
>[...]
> You can easily build a looped space to test it:
> mkdir /tmp/y
> mkdir /tmp/y/z
> bind /tmp /tmp/y/z
> # have fun
>
Since this is by error'ing that one learns, I learned a lot today!
--
Thierry Laronde
It was a long time ago, but I think some versions of du used dev/ino to
avoid counting the same file twice.
On 13 January 2012 17:02, wrote:
> I never thought that perhaps, under Unices, du(1) with hard links will
> produce the same misleading result...
>
tlaro...@polynum.com a écrit :
I never thought that perhaps, under Unices, du(1) with hard links will
produce the same misleading result...
And fortunately, Unices 'du' handles this correctly!
(-l option toggles the counting of hardlinked files several times or
not)
Nicolas
> the UTC. Namespace is a way to manage the nicknames, or the presentation
> of data; to manage different views of the "real" thing, but underneath
> there is an uniq pathname; a pathname finally resolved to something
> (no infinite recursion).
what "real" thing? from the perspective of a user p
On Fri, Jan 13, 2012 at 06:24:39PM +0100, Nicolas Bercher wrote:
> tlaro...@polynum.com a écrit :
> >I never thought that perhaps, under Unices, du(1) with hard links will
> >produce the same misleading result...
>
> And fortunately, Unices 'du' handles this correctly!
> (-l option toggles the cou
On Fri, Jan 13, 2012 at 12:37:17PM -0500, erik quanstrom wrote:
>[...]
> each file server has a unique path name, called the qid (as charles
> mentioned). but between (instances of) file servers, qids are not unique.
But a "fully qualified qid", I mean, at this very moment, for the
kernel, a res
> > each file server has a unique path name, called the qid (as charles
> > mentioned). but between (instances of) file servers, qids are not unique.
/dev/pid has a different size depending on what your pid happens to be. so
i think your statement is still too strong.
> I will not exchange the
please note that the sum du returns may be bigger than the actual
storage used anyway - think deduping and compression done at venti
level.
well, there is a session persistense in Plan 9, and its name is vncs(1)…
On Fri Jan 13 16:01:35 EST 2012, yari...@gmail.com wrote:
> please note that the sum du returns may be bigger than the actual
> storage used anyway - think deduping and compression done at venti
> level.
not everyone has a venti.
- erik
that's very true. i rely on that quite a bit, generating new copies
frequently, expecting that it won't consume much more space.
On 13 January 2012 21:00, Yaroslav wrote:
> think deduping and compression done at venti
On Fri Jan 13 17:16:01 EST 2012, charles.fors...@gmail.com wrote:
> that's very true. i rely on that quite a bit, generating new copies
> frequently, expecting that it won't consume much more space.
an extra copy or 100 of the distribution
will be <1% of a new hard drive, even with
no de-dup.
-
erik quanstrom wrote:
> an extra copy or 100 of the distribution
> will be <1% of a new hard drive, even with
> no de-dup.
Sure, but there's other data than that. I do music, as a hobby. A
project for an electronic track can have 20GB because everything I use
is "statically linked" into it. Doin
but if you insert extra music in front of your track dedup in venti won't help.
or would it?
On Sat, Jan 14, 2012 at 12:10 AM, Aram Hăvărneanu wrote:
> erik quanstrom wrote:
>> an extra copy or 100 of the distribution
>> will be <1% of a new hard drive, even with
>> no de-dup.
>
> Sure, but there
On Sat, Jan 14, 2012 at 12:14 AM, Francisco J Ballesteros wrote:
> but if you insert extra music in front of your track dedup in venti won't
> help.
> or would it?
It wouldn't. In practice it seems that it usually appends, probably
for performance reasons, so for me it had worked so far absolute
dedubstep!
--
cinap
On Sat, 14 Jan 2012 00:14:25 +0100 Francisco J Ballesteros
wrote:
> but if you insert extra music in front of your track dedup in venti won't
> help.
> or would it?
No. Venti operates at block level.
You are better off using an SCM like mercurial (though commits
are likely to be slow). In ca
On Fri, Jan 13, 2012 at 1:05 PM, Yaroslav wrote:
> well, there is a session persistense in Plan 9, and its name is vncs(1)…
>
Opening mibbit in a web browser is easier than installing a VNC client
on every computer I use.
Do you have some personal problem with IRC bouncers that makes you
despera
On Saturday 14 January 2012 01:30:32 Bakul Shah wrote:
> On Sat, 14 Jan 2012 00:14:25 +0100 Francisco J Ballesteros
wrote:
> > but if you insert extra music in front of your track dedup in venti won't
> > help. or would it?
>
> No. Venti operates at block level.
there are two ways around it a
38 matches
Mail list logo
