Re: ext3 on root filesystem problem

2000-07-23 Thread Andreas Dilger

Jeremy writes:
> For some reason I can't get ext3 on my root filesystem (I've been
> successful before so I think I'm doing it right).
> 
> Basically what happens is I get a panic because it cannot create the
> journal.  It claims that it has tried to access beyond the end of the
> device.  Here's the output:
> 
> Ext3-fs: error(device ramdisk(1,0)): ext3_get_inode_loc: bad inode
> number: 1133
> Journal length (0 blocks) too short.
> Ext3-fs: error creating journal.
> attempt to access beyond end of device.
> 01:00: rw=1, want=2147483644, limit=4096 dev 01:00 blksize=1024 blocknr=-5
> sector=-10 size=1024 count=1
> 
> From the looks of it, it seems I passed the wrong inode number, but I
> double checked many times and I have the right number.

It does indeed look like the wrong inode is being used.  However, I suspect
that one of the reasons this is a problem is because you are trying to
set up a journal on a ramdisk?  I doubt this is at all useful because the
journal on the ramdisk is deleted when the system shuts down.

Probably what you want is to have the journal for the root partition.  You
only need to give the "journal=" option the _first_ time that the
filesystem is mounted as ext3.  If you are booting from ramdisk, you could
add an option (maybe /etc/fstab?) so that the root filesystem has the
correct journal option, rather than putting it in /etc/lilo.conf.  Otherwise,
you could try booting without the ramdisk (if this is possible on your
system), or create a boot floppy with ext3 support and simply mount the
root filesystem once manually.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert



Re: ext3 on root filesystem problem

2000-07-23 Thread Jeremy Hansen


Hmm...no, I'm not booting from a ramdisk.  The only ramdisk involved is to
initialize my scsi adapter and I've already successfully install the
journal on my scsi drive's partition.

My root filesystem is on hda3, which is just my first bootable
drive.  There should be no ramdisk involved with that.

I thought about what you suggest, just putting things in fstab, but then I
fear not being able to boot.

-jeremy

> 
> It does indeed look like the wrong inode is being used.  However, I suspect
> that one of the reasons this is a problem is because you are trying to
> set up a journal on a ramdisk?  I doubt this is at all useful because the
> journal on the ramdisk is deleted when the system shuts down.
> 
> Probably what you want is to have the journal for the root partition.  You
> only need to give the "journal=" option the _first_ time that the
> filesystem is mounted as ext3.  If you are booting from ramdisk, you could
> add an option (maybe /etc/fstab?) so that the root filesystem has the
> correct journal option, rather than putting it in /etc/lilo.conf.  Otherwise,
> you could try booting without the ramdisk (if this is possible on your
> system), or create a boot floppy with ext3 support and simply mount the
> root filesystem once manually.
> 
> Cheers, Andreas
> 

-- 

http://www.xxedgexx.com | [EMAIL PROTECTED]
-




Re: [RFC] Quotafile format

2000-07-23 Thread Jan Kara

> Jan Kara wrote:
> > 
> >   Hello.
> > 
> >   I'm working on new quotafile format (to be ready for inclusion in 2.5). As a
> > benefit we should be able to support 32-bit UIDs with quotas and also space
> > will be accounted in bytes not in blocks (this is needed for ReiserFS).
> > But there is one problem with byte accounting - there is no way to get
> > real number of bytes file occupies. i_size includes holes and i_blocks
> > is in blocks. Does anybody see any other way than creating new field
> > in inode like i_realsize or something like that?
> 
> Quotas should count the disk space consumed by a file, not the file size
> in bytes. The question is how to correctly report that information if
> it's smaller than blocks. st_blocks of struct stat is the number of
> blocks allocated, for example. Granularity smaller than 1024 bytes may
> still be a good thing for other file systems (sub-block allocation).
  I know this (BTW st_blocks is in 512 bytes if I remember well) I was
just too lazy to write it precisely ;)

> I have another related problem with my extended attributes patch
> (extended attributes of a file also require some disk space, obviously).
> I'm adding the blocks consumed by EAs to the i_blocks field. That way,
> even quotacheck works as expected.
  Here's another problem that I need to propagate something like i_blocks
but in bytes to userspace (for quotacheck). It probably means another
entry to stat structure...

Bye
Honza




Quotas in reiserfs

2000-07-23 Thread Jan Kara

  Hello.

  So I've finally written quotas for reiserfs (sorry it took so long).
First I have few notes about things I think might be bugs in reiserfs:

i_blksize initialized twice in reiserfs_new_inode() - PAGE_SIZE should be right.

i_nlink should be set to 0 when we fail in reiserfs_new_inode(). Otherwise
inode never gets deleted (and so among other things we have quota leak...).

One unimportant (code is currently behind #if 0):
In get_new_buffer_near_blocknr() should rather be called reiserfs_new_unf_blocknrs() 
than
reiserfs_new_blocknrs().

In reiserfs_get_block() when reiserfs_new_unf_blocknrs() returns something like
IO error we continue but we should rather return with an error...

And now to quotas: Currently chown and chgrp and also quotacheck doesn't work
well as we have no way of counting used space by inode in bytes. I will probably
create new entry in inode but at first I'd like to hear some comments from
other hackers... Other things should work reasonably well. Currently only
bodies of items are accounted to disk quota as number of items (and so space
spent on headers) might change during balancing and it wouldn't be nice to mess
with it :) Also number of files is accounted as number of inodes. I don't
say anybody will use it but why should we have unused capacity :-).

All patches are currently against 2.4.0-test3.
quota-patch-2.4.0-test3.diff is patch for new quotafile format which is needed
for byte allocation.
reiserquota-patch-2.4.0-test3.diff is patch for quota to reiserfs.
quota-3.00.tar.gz is package with utilities working with quotafiles with new
format.
Patches are currently at: ftp://atrey.karlin.mff.cuni.cz/ftp/pub/local/jack/quota/
quotafile patch in directory v2.4/
reiserfs patch in directory reiserfs/
utilities in directory utils/

I'll also put the things on suse.cz ftp when I find how ;-) (probably on tuesday).

Awaiting bug reports :)

Bye
Honza




Reiserfs quota

2000-07-23 Thread Jan Kara

  Hello.

  There is mistake in address of patches (in directory). It's:
ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/

Honza