[reiserfs-list] /etc/fstab

2001-05-19 Thread Krasi Zlatev


I do not want to put in /etc/fstab, because the partition is mounted at
start up.
/dev/hdd5  /mnt5   reiserfs  notail,noatime0 0
How to mount it manually what options should I give to mount?
Thanks.




Re: [reiserfs-list] /etc/fstab

2001-05-19 Thread Matthias Andree

Krasi Zlatev [EMAIL PROTECTED] writes:

 I do not want to put in /etc/fstab, because the partition is mounted at
 start up.
 /dev/hdd5  /mnt5   reiserfs  notail,noatime0 0
 How to mount it manually what options should I give to mount?

The same :-)

You can add noauto to the fstab options to prevent mount on boot.

See man fstab.

-- 
Matthias Andree



Re: [reiserfs-list] [patch] ignore forcefsck

2001-05-19 Thread Hans Reiser

Vladimir V. Saveliev wrote:
 
 Vladimir V. Saveliev wrote:
 
  For now we do not want it to be ran by boot scripts. So, 3.x.0k will just ignore
  -f and -a.
 
 Ooops, I meant: -f and -a will make reiserfsck to do nothing but print its version.
 
 whereas -r and -p are ignored.
 
 Thanks,
 vs
Actually, I would like them to say:  reiserfsck is being run with -f or -a,
which usually means that your distro maintainer hasn't bothered to adjust the
boot scripts to not run fsck on journaling filesystems that don't need or want
it.  Sigh.  Doing nothing.  We suggest fixing the boot script.

Hans



Re: [reiserfs-list] filesystem interfaces

2001-05-19 Thread Matthias Andree

Ragnar Kjørstad [EMAIL PROTECTED] writes:

 1. fsync
 
 The current fsync interface lacks a couple of interesting features. I
 believe lazy-fsync has been discussed, but another useful feature is

Wait a minute. The major problem is that mail-servers, regardless of
their performance efforts, need to be safe in that they *NEVER* lose any
mail. Trading speed for lost mail over a crash is not a good deal.

An architecture which defers fsync() for a finite, maximum amount of
time to gather multiple fsync() requests into a batch of (possibly
sorted, sent into a tagged SCSI command queue) writes and then
acknowledging all at once may be a good idea, provided you don't run out
of process table slots with all those waiting smtpds, and a mail server
can not acknowledge receipt of a mail before all file and meta data is
on disk (and not in a fast write cache or something).

 The caller should be able to wait for fsync to complete by using poll in
 the case of asyn fsync.

It would require introducing a special syscall, I believe. However, in
that case, fsync should also sync all meta data related to files.

A different aspect is that many mailers expect BSD-type directory
modifications are always synchronous semantics. Revisit the
ReiserFS-and-qmail issue. On ext2, you can circumvent the problems with
chattr +S, but on ReiserFS, there is no such thing. 



 Now link and rename behaves differently with regards to replacing
 existing files, but what's the logic behind this?

What's the problem with that? 

To clobber, use rename.

To be careful, use link and if that succeeds, unlink.

How would you like to establish the atomicity of either functionality
(either rename or link (without unlink)) in your approach?



 3. Ruby
 
 I just came across the ruby programming language today - the interesting
 thing is that this language has a concept of transactions! Does any
 other languages have this kind of features? Do anyone use them for real
 software? It would be really cool with a ruby-implementation that
 actually used filesystem-transactions to implement this instead of the
 library implementation that I assume ruby uses.

That would probably be most useful in things like NFS where a link may
succeed, but the success report fails. If this was transaction-oriented,
the check if your file's st.n_link has increased to 2, if so, your link
has succeeded could be avoided.

Not sure if Coda or AFS have concepts like these.

-- 
Matthias Andree



Re: [reiserfs-list] ftp.reiserfs.org down?

2001-05-19 Thread Hans Reiser

Dirk Haage wrote:
 
 On 18 May 2001 10:17:03 -0700, Hans Reiser wrote:
  Vladimir V. Saveliev wrote:
  
   You should use ftp.namesys.com.
  
   Thanks,
   vs
  It should be fixed by now, and reiserfs.org and reiserfs.net should work by now.
 
 
 Hmm, I just get some Infos from domaindiscover, that reiserfs.net/org is
 reserved :(
 
 /dirk
reserved by me?

Hans



Re: [reiserfs-list] [patch] ignore forcefsck

2001-05-19 Thread Hans Reiser

Dirk Mueller wrote:
 
 On Sam, 19 Mai 2001, Hans Reiser wrote:
 
  fsck should never be run automatically.  That sysadmin might have a company
  waiting for the server to come up.
 
 Then they should have a sysadmin that knows how to disable it.
 
 This is not a policy, its just a reasonable default. I don't like much that
 reiserfs does not integrate into the standard fdisk after a while sheme
 the usual file systems do.
 
 Dirk
usual file systems don't do it.  netapp sure doesn't.

hans



Re: [reiserfs-list] [patch] ignore forcefsck

2001-05-19 Thread Hans Reiser

Chris Mason wrote:
 
 On Saturday, May 19, 2001 06:40:48 PM +0200 Dirk Mueller [EMAIL PROTECTED]
 wrote:
 
  On Sam, 19 Mai 2001, Hans Reiser wrote:
 
  fsck should never be run automatically.  That sysadmin might have a
  company waiting for the server to come up.
 
  Then they should have a sysadmin that knows how to disable it.
 
  This is not a policy, its just a reasonable default. I don't like much
  that  reiserfs does not integrate into the standard fdisk after a
  while sheme  the usual file systems do.
 
 
 There are two sides of this.  fsck is only now getting strong enough that I
 would start to recommend that kind of thing.  As fsck matures, we should at
 least have the option of ext2 style automatic runs after X number of
 mounts/crashes.
 
 -chris
No, this is an absolutely hideous feature of ext2, if you want to have it print
a reminder to the user that they have not run fsck recently, fine, but in the
eyes of a suser trying to get their laptop to turn on for their presentation, or
their server to not leave the whole company hanging, this feature of ext2 fsck
is a bug.



Re: [reiserfs-list] [patch] ignore forcefsck

2001-05-19 Thread Ed Tomlinson

On Saturday 19 May 2001 12:28, Hans Reiser wrote:
 fsck should never be run automatically.  That sysadmin might have a company
 waiting for the server to come up.

Conversly that sysadmin might be hours away from the box that needs to be fscked
before restarting...  In this case, which _does_ happen, an automatic fsck can
be a good thing.

I administer a SAP systems.

Ed Tomlinson [EMAIL PROTECTED]



Re: [reiserfs-list] [patch] ignore forcefsck

2001-05-19 Thread Chris Mason



On Saturday, May 19, 2001 11:31:29 AM -0700 Hans Reiser
[EMAIL PROTECTED] wrote:

 Chris Mason wrote:
 
 On Saturday, May 19, 2001 06:40:48 PM +0200 Dirk Mueller [EMAIL PROTECTED]
 wrote:
 
  On Sam, 19 Mai 2001, Hans Reiser wrote:
  
  fsck should never be run automatically.  That sysadmin might have a
  company waiting for the server to come up.
  
  Then they should have a sysadmin that knows how to disable it.
  
  This is not a policy, its just a reasonable default. I don't like much
  that  reiserfs does not integrate into the standard fdisk after a
  while sheme  the usual file systems do.
  
 
 There are two sides of this.  fsck is only now getting strong enough
 that I would start to recommend that kind of thing.  As fsck matures, we
 should at least have the option of ext2 style automatic runs after X
 number of mounts/crashes.
 
 -chris
 No, this is an absolutely hideous feature of ext2, if you want to have it
 print a reminder to the user that they have not run fsck recently, fine,
 but in the eyes of a suser trying to get their laptop to turn on for
 their presentation, or their server to not leave the whole company
 hanging, this feature of ext2 fsck is a bug.

No.  There are many, many different kinds of users.  The home user, where
fsck should only take a few minutes, should have an (readonly) fsck every
once and a while to make sure the FS is correct, especially since these
users tend to not have backups.

It is a very good feature, that not everyone needs.  Huge installations
don't want periodic fscks, but huge installations are the exception, not
the rule.

-chris






Re: [reiserfs-list] [patch] ignore forcefsck

2001-05-19 Thread Stefan Traby

On Sat, May 19, 2001 at 11:31:29AM -0700, Hans Reiser wrote:

  There are two sides of this.  fsck is only now getting strong enough that I
  would start to recommend that kind of thing.  As fsck matures, we should at
  least have the option of ext2 style automatic runs after X number of
  mounts/crashes.

 No, this is an absolutely hideous feature of ext2, if you want to have it print
 a reminder to the user that they have not run fsck recently, fine, but in the
 eyes of a suser trying to get their laptop to turn on for their presentation, or
 their server to not leave the whole company hanging, this feature of ext2 fsck
 is a bug.

Sorry. It's never a bug.
You can control the behavior quite easily by tune2fs.

Mount count:  3
Maximum mount count:  20
Last checked: Thu May  3 04:16:07 2001
Check interval:   15552000 (6 months)

So it's clearly a feature that makes sense at least in some
environments.

-- 

  ciao - 
Stefan

  Man gebe jedem Niedersachsen - seinen eigenen Castor-Kasten.  

Stefan TrabyLinux/ia32   fax:  +43-3133-6107-9
Mitterlasznitzstr. 13   Linux/alphaphone: +43-699-10157505
8302 Nestelbach Linux/sparc   http://www.hello-penguin.com
Austria  mailto:[EMAIL PROTECTED]
Europe mailto:[EMAIL PROTECTED]



Re: [reiserfs-list] What about this one liner in fix_node.c?

2001-05-19 Thread Chris Mason



On Sunday, May 20, 2001 12:07:33 AM +0200 Dieter Nützel
[EMAIL PROTECTED] wrote:

 Hello Chris,
  is this one usefull or obsolete?
  diff -ur linux/fs/reiserfs/fix_node.c linux/fs/reiserfs/fix_node.c
 --- linux/fs/reiserfs/fix_node.c   Mon Jan 15 18:31:19 2001
 +++ linux/fs/reiserfs/fix_node.cFri Feb  2 15:40:54 2001
 @@ -936,6 +936,7 @@
  if (p_s_tb-FEB[p_s_tb-cur_blknum])
BUG();
   +mark_buffer_journal_new(p_s_new_bh) ;
  p_s_tb-FEB[p_s_tb-cur_blknum++] = p_s_new_bh;
}
 
Still useful, but not strictly a bug fix so it hasn't gone in yet.  Without
the patch, very balance instensive ops are a little slower (but not much).

-chris