Date: Tue, 10 Jun 1997 16:58:22 +0300 (EEST) From: Narvi <narvi@haldjas.folklore.ee> To: Gilles Bruno <Gilles.Bruno@ujf-grenoble.fr> Cc: hackers@FreeBSD.ORG Subject: Re: mmap() question... Message-ID: <Pine.BSF.3.96.970610162233.6631A-100000@haldjas.folklore.ee> In-Reply-To: <2.2.32.19970610103948.008c4cdc@adm.ujf-grenoble.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 10 Jun 1997, Gilles Bruno wrote:
> Hi everyone !
> (here we go for some kind of newbie question...)
>
> I tried -for testing purpose- to implement the FAST_SHARE_MODE feature of
> samba-1.9.16p11 on a FreeBSD 2.2.2-Release box. This implies the use of
> both mmap() and lockf() systems calls.
> After doing some minimal hacking in the samba source tree (mainly to replace
> sysV lockf() call with the bsd's flock() in shmem.c) I managed to get it work.
>
> *BUT* when I took a look in the (standard) /usr/local/samba/var/lock where the
> shared mem file resides, I found the following :
>
> {423}Root /bin/ls -a -l /usr/local/samba/var/locks
> total 60
> drwxr-xr-x 2 root wheel 512 Jan 28 11:19 .
> drwxr-xr-x 3 root wheel 512 Jan 28 11:36 ..
> -rw-rw-rw- 1 root wheel 102400 Jan 28 11:26 SHARE_MEM_FILE
> -rw-rw-rw- 1 root wheel 4294967304 Jan 28 12:04
> SHARE_MEM_FILE.processes
> ^^^^^^^^^^
> -rw-r--r-- 1 root wheel 200 Jan 28 12:04 STATUS..LCK
> -rw-r--r-- 1 root wheel 77 Jan 28 11:19 browse.dat
> -rw-r--r-- 1 root wheel 0 Jan 28 11:19 wins.dat
>
> Hike ! What's that ?
A sparse file, I would say.
>
> {425}Root /usr/bin/du /usr/local/samba/var/locks
> 59 /usr/local/samba/var/locks
>
> {426}Root /usr/bin/du
> /usr/local/samba/var/locks/SHARE_MEM_FILE.processes
> 32 /usr/local/samba/var/locks/SHARE_MEM_FILE.processes
With actually only 32K of space...
>
> I presume that the size of the "SHARE_MEM_FILE.processes" (4Gb !)
> reflects some sort of maximum addressable memory, isn't it ?
For some reason, it thinks it needs to have the whole 32bit addrress space
covered by its processes.
>
> It would disturb me, if this directory had to be BACKED UP (using
> dump/amanda)...
> (I presume it wouldn't hurt since the real amount of space taken by this
> file is 32k,
> but if the dump use the same 'stat' method the /bin/ls does it would... No ?)
>
Doesn't dump support sparse files? I think I've heard even tar does, but I
may be mistaken.
> The same question also applies to the /stand directory wich contains gzip
> executables
> (whose size is 1064960 bytes...)
These gzip executables are 1064960 bytes. Actually, there is only one
executable taht is hard-linked into many diffrent names and carries out
different function depending on the name it was called on....
> ----------------------------------------------------------------------------
> ----------
> Resume :
> . am I correct in my assertions / the size of this particular file
It is a 4GB sparse file containing 32Kb data.
> . is the output of the ls command 'normal' ?
I think yes. The size of the file is 4GB.
> . will this 'odditie' disturb either dump or tar (I'm concerned/anxious
> about 'tar')
>
I don't think it will.
Sander
> PS. Oops. Look's like I haven't set the time zone of this test box yet...
> Don't blame my poor english...
> --
> Gilles BRUNO
> Universite Joseph Fourier - CRIP
> Domaine Universitaire 38041 St Martin d'Heres FRANCE
> Tel (33) 04 76 63 56 68 Fax (33) 04 76 51 42 74
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970610162233.6631A-100000>