9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] p9p venti w/ raw partitions
@ 2008-06-24  2:34 a
  2008-06-24 11:47 ` Russ Cox
  0 siblings, 1 reply; 7+ messages in thread
From: a @ 2008-06-24  2:34 UTC (permalink / raw)
  To: 9fans

Is anyone running venti with raw disk partitions on Unix? I've got a
nice large disk to dedicate to it, and would like to do it without
needlessly imposing another fs, if possible, but am running into
problems. The blocker now is fmtarenas is complaining that it
"can't determine size of partition" for raw disk partitions.
Anthony




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [9fans] p9p venti w/ raw partitions
  2008-06-24  2:34 [9fans] p9p venti w/ raw partitions a
@ 2008-06-24 11:47 ` Russ Cox
  2008-06-24 12:16   ` a
  2008-06-25  1:14   ` a
  0 siblings, 2 replies; 7+ messages in thread
From: Russ Cox @ 2008-06-24 11:47 UTC (permalink / raw)
  To: 9fans

> Is anyone running venti with raw disk partitions on Unix? I've got a
> nice large disk to dedicate to it, and would like to do it without
> needlessly imposing another fs, if possible, but am running into
> problems. The blocker now is fmtarenas is complaining that it
> "can't determine size of partition" for raw disk partitions.

I've used raw disk partitions on FreeBSD recently,
and raw disk partitions on Linux a while back.
What OS are you running, and what does

	9 ls -l /dev/your-disk

print?  Assuming it prints a size of 0, you need to figure
out how to get the real disk size out of the kernel.
See /usr/local/plan9/src/lib9/_p9dir.c.

Russ



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [9fans] p9p venti w/ raw partitions
  2008-06-24 11:47 ` Russ Cox
@ 2008-06-24 12:16   ` a
  2008-06-24 12:57     ` Pietro Gagliardi
  2008-06-25  1:14   ` a
  1 sibling, 1 reply; 7+ messages in thread
From: a @ 2008-06-24 12:16 UTC (permalink / raw)
  To: 9fans

OS X. And yes, 9's ls reports size zero (as opposed to
OSX's ls "size" of "14,  12"). I'll spend a little time on
it this morning and see what i get. OS X's stat(1) can
get the info, so the hardest part might just be
figuring out which "project" Apple put the source for
stat in.
Anthony




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [9fans] p9p venti w/ raw partitions
  2008-06-24 12:16   ` a
@ 2008-06-24 12:57     ` Pietro Gagliardi
  0 siblings, 0 replies; 7+ messages in thread
From: Pietro Gagliardi @ 2008-06-24 12:57 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Jun 24, 2008, at 8:16 AM, a@9srv.net wrote:

> OS X. And yes, 9's ls reports size zero (as opposed to
> OSX's ls "size" of "14,  12"). I'll spend a little time on

These "sizes" are the major and minor device numbers.

>
> it this morning and see what i get. OS X's stat(1) can
> get the info, so the hardest part might just be
> figuring out which "project" Apple put the source for
> stat in.
> Anthony
>
>

$ stat /dev/disk0
46138868 46908804 brw-r----- 1 root operator 234881024 0 "Jun 21
19:55:38 2008" "Jun 21 19:55:38 2008" "Jun 21 19:55:38 2008" "Jun 21
19:55:38 2008" 2048 0 0 /dev/disk0
$ stat -l /dev/disk0
brw-r----- 1 root operator 14,0 Jun 21 19:55:38 2008 /dev/disk0
$ stat -f '%z' /dev/disk0
0

So oh well.

Using Apple's diskutil seems to work:

$ diskutil info /dev/disk0
#...
    Total Size:               232.9 Gi (250059350016 B) (488397168 512-
byte blocks)
    Free Space:               0.0 B (0 B) (0 512-byte blocks)
# ...




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [9fans] p9p venti w/ raw partitions
  2008-06-24 11:47 ` Russ Cox
  2008-06-24 12:16   ` a
@ 2008-06-25  1:14   ` a
  2008-06-25 10:45     ` Russ Cox
  1 sibling, 1 reply; 7+ messages in thread
From: a @ 2008-06-25  1:14 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

I wasn't able to get this working today, but I believe I made good
progress. Unfortunately, I'm traveling all day tomorrow and will
have questionable network access while away for about a week.

I've attached my version of _p9dir.c with the OS X code in it. The
addition is pretty simple, and I tested a dummy program with
nearly the same code and it prints the real size in bytes, but
something isn't right. I rebuilt and installed lib9 and ls, but ls
still doesn't show anything useful. It may just be that I have to
rebuild something more than I have. Forwarded in the hope that
someone who's looked at p9p's guts more than I can tell me
what that might be.
Anthony

[-- Attachment #2: _p9dir.c --]
[-- Type: text/plain, Size: 5962 bytes --]

#include <u.h>
#define NOPLAN9DEFINES
#include <libc.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <dirent.h>
#include <pwd.h>
#include <grp.h>

#if defined(__FreeBSD__)
#include <sys/disk.h>
#include <sys/disklabel.h>
#include <sys/ioctl.h>
#endif

#if defined(__OpenBSD__)
#include <sys/disklabel.h>
#include <sys/ioctl.h>
#define _HAVEDISKLABEL
static int diskdev[] = {
	151,	/* aacd */
	116,	/* ad */
	157,	/* ar */
	118,	/* afd */
	133,	/* amrd */
	13,	/* da */
	102,	/* fla */
	109,	/* idad */
	95,	/* md */
	131,	/* mlxd */
	168,	/* pst */
	147,	/* twed */
	43,	/* vn */
	3,	/* wd */
	87,	/* wfd */
	4,	/* da on FreeBSD 5 */
};
static int
isdisk(struct stat *st)
{
	int i, dev;

	if(!S_ISCHR(st->st_mode))
		return 0;
	dev = major(st->st_rdev);
	for(i=0; i<nelem(diskdev); i++)
		if(diskdev[i] == dev)
			return 1;
	return 0;
}
#endif

#if defined(__FreeBSD__)	/* maybe OpenBSD too? */
char *diskdev[] = {
	"aacd",
	"ad",
	"ar",
	"afd",
	"amrd",
	"da",
	"fla",
	"idad",
	"md",
	"mlxd",
	"pst",
	"twed",
	"vn",
	"wd",
	"wfd",
	"da",
};
static int
isdisk(struct stat *st)
{
	char *name;
	int i, len;

	if(!S_ISCHR(st->st_mode))
		return 0;
	name = devname(st->st_rdev, S_IFCHR);
	for(i=0; i<nelem(diskdev); i++){
		len = strlen(diskdev[i]);
		if(strncmp(diskdev[i], name, len) == 0 && isdigit((uchar)name[len]))
			return 1;
	}
	return 0;
}
#endif


#if defined(__linux__)
#include <linux/hdreg.h>
#include <linux/fs.h>
#include <sys/ioctl.h>
#undef major
#define major(dev) ((int)(((dev) >> 8) & 0xff))
static vlong
disksize(int fd, int dev)
{
	u64int u64;
	long l;
	struct hd_geometry geo;

	memset(&geo, 0, sizeof geo);
	l = 0;
	u64 = 0;
#ifdef BLKGETSIZE64
	if(ioctl(fd, BLKGETSIZE64, &u64) >= 0)
		return u64;
#endif
	if(ioctl(fd, BLKGETSIZE, &l) >= 0)
		return l*512;
	if(ioctl(fd, HDIO_GETGEO, &geo) >= 0)
		return (vlong)geo.heads*geo.sectors*geo.cylinders*512;
	return 0;
}
#define _HAVEDISKSIZE
#endif

#if defined(__APPLE__)
#include <sys/disk.h>
static vlong
disksize(int fd, int dev)
{
	u64int blockCount;
	u32int blockSize;

	ioctl(fd, DKIOCGETBLOCKSIZE, &blockSize);
	ioctl(fd, DKIOCGETBLOCKCOUNT, &blockCount);
	if(blockSize >0 && blockCount > 0)
		return blockCount*blockSize;
	return 0;
}
#define _HAVEDISKSIZE
#endif

#if !defined(__linux__) && !defined(__sun__)
#define _HAVESTGEN
#endif

int _p9usepwlibrary = 1;
/*
 * Caching the last group and passwd looked up is
 * a significant win (stupidly enough) on most systems.
 * It's not safe for threaded programs, but neither is using
 * getpwnam in the first place, so I'm not too worried.
 */
int
_p9dir(struct stat *lst, struct stat *st, char *name, Dir *d, char **str, char *estr)
{
	char *s;
	char tmp[20];
	static struct group *g;
	static struct passwd *p;
	static int gid, uid;
	int sz, fd;

	fd = -1;
	USED(fd);
	sz = 0;
	if(d)
		memset(d, 0, sizeof *d);

	/* name */
	s = strrchr(name, '/');
	if(s)
		s++;
	if(!s || !*s)
		s = name;
	if(*s == '/')
		s++;
	if(*s == 0)
		s = "/";
	if(d){
		if(*str + strlen(s)+1 > estr)
			d->name = "oops";
		else{
			strcpy(*str, s);
			d->name = *str;
			*str += strlen(*str)+1;
		}
	}
	sz += strlen(s)+1;

	/* user */
	if(p && st->st_uid == uid && p->pw_uid == uid)
		;
	else if(_p9usepwlibrary){
		p = getpwuid(st->st_uid);
		uid = st->st_uid;
	}
	if(p == nil || st->st_uid != uid || p->pw_uid != uid){
		snprint(tmp, sizeof tmp, "%d", (int)st->st_uid);
		s = tmp;
	}else
		s = p->pw_name;
	sz += strlen(s)+1;
	if(d){
		if(*str+strlen(s)+1 > estr)
			d->uid = "oops";
		else{
			strcpy(*str, s);
			d->uid = *str;
			*str += strlen(*str)+1;
		}
	}

	/* group */
	if(g && st->st_gid == gid && g->gr_gid == gid)
		;
	else if(_p9usepwlibrary){
		g = getgrgid(st->st_gid);
		gid = st->st_gid;
	}
	if(g == nil || st->st_gid != gid || g->gr_gid != gid){
		snprint(tmp, sizeof tmp, "%d", (int)st->st_gid);
		s = tmp;
	}else
		s = g->gr_name;
	sz += strlen(s)+1;
	if(d){
		if(*str + strlen(s)+1 > estr)
			d->gid = "oops";
		else{
			strcpy(*str, s);
			d->gid = *str;
			*str += strlen(*str)+1;
		}
	}

	if(d){
		d->type = 'M';

		d->muid = "";
		d->qid.path = ((uvlong)st->st_dev<<32) | st->st_ino;
#ifdef _HAVESTGEN
		d->qid.vers = st->st_gen;
#endif
		if(d->qid.vers == 0)
			d->qid.vers = st->st_mtime + st->st_ctime;
		d->mode = st->st_mode&0777;
		d->atime = st->st_atime;
		d->mtime = st->st_mtime;
		d->length = st->st_size;

		if(S_ISDIR(st->st_mode)){
			d->length = 0;
			d->mode |= DMDIR;
			d->qid.type = QTDIR;
		}
		if(S_ISLNK(lst->st_mode))	/* yes, lst not st */
			d->mode |= DMSYMLINK;
		if(S_ISFIFO(st->st_mode))
			d->mode |= DMNAMEDPIPE;
		if(S_ISSOCK(st->st_mode))
			d->mode |= DMSOCKET;
		if(S_ISBLK(st->st_mode)){
			d->mode |= DMDEVICE;
			d->qid.path = ('b'<<16)|st->st_rdev;
		}
		if(S_ISCHR(st->st_mode)){
			d->mode |= DMDEVICE;
			d->qid.path = ('c'<<16)|st->st_rdev;
		}
		/* fetch real size for disks */
#ifdef _HAVEDISKSIZE
		if(S_ISBLK(st->st_mode) && (fd = open(name, O_RDONLY)) >= 0){
			d->length = disksize(fd, major(st->st_dev));
			close(fd);
		}
#endif
#if defined(DIOCGMEDIASIZE)
		if(isdisk(st)){
			int fd;
			off_t mediasize;

			if((fd = open(name, O_RDONLY)) >= 0){
				if(ioctl(fd, DIOCGMEDIASIZE, &mediasize) >= 0)
					d->length = mediasize;
				close(fd);
			}
		}
#elif defined(_HAVEDISKLABEL)
		if(isdisk(st)){
			int fd, n;
			struct disklabel lab;

			if((fd = open(name, O_RDONLY)) < 0)
				goto nosize;
			if(ioctl(fd, DIOCGDINFO, &lab) < 0)
				goto nosize;
			n = minor(st->st_rdev)&7;
			if(n >= lab.d_npartitions)
				goto nosize;

			d->length = (vlong)(lab.d_partitions[n].p_size) * lab.d_secsize;

		nosize:
			if(fd >= 0)
				close(fd);
		}
#endif
	}

	return sz;
}

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [9fans] p9p venti w/ raw partitions
  2008-06-25  1:14   ` a
@ 2008-06-25 10:45     ` Russ Cox
  0 siblings, 0 replies; 7+ messages in thread
From: Russ Cox @ 2008-06-25 10:45 UTC (permalink / raw)
  To: 9fans

> something isn't right. I rebuilt and installed lib9 and ls, but ls
> still doesn't show anything useful. It may just be that I have to

My first guess would be that when you "installed" ls again,
there was already an o.ls in plan9/src/cmd, so it didn't
get relinked.  It should suffice to do

	cd $PLAN9/src/lib9
	mk _p9dir
	cd ../cmd
	rm o.ls
	mk o.ls
	o.ls -l /your/dev

to test.

Russ



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [9fans] p9p venti w/ raw partitions
@ 2008-06-24 12:38 erik quanstrom
  0 siblings, 0 replies; 7+ messages in thread
From: erik quanstrom @ 2008-06-24 12:38 UTC (permalink / raw)
  To: a, 9fans

> OS X. And yes, 9's ls reports size zero (as opposed to
> OSX's ls "size" of "14,  12"). I'll spend a little time on

those are the major and minor numbers, not the size.
this is traditional unix behavior.

- erik



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2008-06-25 10:45 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-06-24  2:34 [9fans] p9p venti w/ raw partitions a
2008-06-24 11:47 ` Russ Cox
2008-06-24 12:16   ` a
2008-06-24 12:57     ` Pietro Gagliardi
2008-06-25  1:14   ` a
2008-06-25 10:45     ` Russ Cox
2008-06-24 12:38 erik quanstrom

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).