arlad dies

André Zúquete avz at sabrina.inesc.pt
Mon Sep 11 01:53:17 CEST 2000


On 8 Sep 2000, Love wrote:

|Date: 08 Sep 2000 19:36:25 +0200
|From: Love <lha at stacken.kth.se>
|To: andre.zuquete at inesc.pt
|Cc: arla-drinkers at stacken.kth.se
|Subject: Re: arlad dies
|
|André Zúquete <avz at sabrina.inesc.pt> writes:
|
|> |Ok, I think I have found the problem. Arlad and xfs get out of sync since
|> |xfs seem to be happy updating the since of the file.
|> |
|> |Note that I haven't tried this patch since I'm out in the
|> |bandwidth-backwaters/forest (vistiting my parents). I haven't hade chance
|> |to check if it compiles or try run the regression tests.
|> 
|> It compiles and it runs. Tkx for the help!
|
|But after talking to Assar yestoday we came to the conclusion that the
|patch is wrong. It will break other things (like callbacks and the syscall
|sequence open("foo", O_CREATE), write(), utimes(), fchmod(), close()).
|
|xfs need to update the filelength.
|
|Now I would like to know more to figure out why this is happening. I have
|tried to reproduce it on a same type of computer (RH6.2, same kernel,
|makedepends) and I also tried to write a small program that did the
|syscalls in the same order as you strace did it. Can you provide debugging
|information ?
|
|I'm intressed in the values of size and entry->status.Length when it
|crashes, also a backtrace from gdb would be valuable. Xfs and arlad trace
|(started with ``fs arladeb all ; fs xfsdebug all'') might be useful.

In the particular case of the makedepend that I've tryed, the values are:

entry->status.Length 0
size                 16

The full stack trace of arlad follows:

#0  abort () at ../sysdeps/generic/abort.c:55
#1  0x4006abae in __assert_fail () at assert.c:59
#2  0x8053d1c in truncate_file (entry=0x40151428, size=16, ce=0x813de00)
    at fcache.c:2257
#3  0x80591eb in cm_ftruncate (fid={Cell = 1, fid = {Volume = 536871942,
        Vnode = 28254, Unique = 430672}}, size=16, ce=0x813de00) at
inter.c:469
#4  0x805c1ec in xfs_message_putattr (fd=5, h=0x402a9008, size=88)
    at messages.c:540
#5  0x806964b in xfs_message_receive (fd=5, h=0x402a9008, size=88) at
xfs.c:208
#6  0x805a69b in process_message (msg_length=88, msg=0x402a9008 "X")
    at kernel.c:91
#7  0x805a75a in sub_thread (v_myself=0x402a9008) at kernel.c:125
#8  0x808987c in Create_Process_Part2 () at lwp_asm.c:629
#9  0xfffefdfc in ?? ()
#10 0x0 in ?? ()

The contents of *entry are:

$1 = {lock = {wait_states = 0 '\000', excl_locked = 2 '\002',
    readers_reading = 0 '\000', num_waiting = 0 '\000'}, fid = {Cell = 1,
    fid = {Volume = 536871942, Vnode = 28280, Unique = 430674}}, refcount = 0,
  host = 1006944658, length = 16, status = {InterfaceVersion = 1,
    FileType = 1, LinkCount = 1, Length = 0, DataVersion = 1, Author = 20256,
    Owner = 20256, CallerAccess = 127, AnonymousAccess = 0,
    UnixModeBits = 420, ParentVnode = 349, ParentUnique = 272942, SegSize = 0,
    ClientModTime = 968629666, ServerModTime = 968629666, Group = 400,
    SyncCount = 0, spare1 = 0, spare2 = 0, spare3 = 0, spare4 = 0},
  callback = {CallBackVersion = 1, ExpirationTime = 968644146,
    CallBackType = 2}, volsync = {spare1 = 727377727, spare2 = 0, spare3 = 0,
    spare4 = 0, spare5 = 0, spare6 = 0}, acccache = {{cred = 2197847808,
      access = 127}, {cred = 0, access = 0}, {cred = 0, access = 0}, {
      cred = 0, access = 0}, {cred = 0, access = 0}, {cred = 0, access = 0}, {
      cred = 0, access = 0}, {cred = 0, access = 0}}, anonaccess = 0,
  index = 38, handle = {
    data = "\002\003\204E\024\225\t\000iE\237¿", '\000' <repeats 67 times>},
  flags = {usedp = 1, attrp = 1, datap = 1, attrusedp = 0, datausedp = 1,
    extradirp = 0, mountp = 0, kernelp = 1, sentenced = 0, silly = 0,
    fake_mp = 0, vol_root = 0}, tokens = 208, parent = {Cell = 0, fid = {
      Volume = 0, Vnode = 0, Unique = 0}}, lru_le = 0x8376a10,
  invalid_ptr = 11, volume = 0x813c5f8, priority = 0, hits = 0, cleanergen = 0}

I've tryed the command ``fs arladeb all'' but nothing happens. On the
contrary, with ``fs xfsdebug all'' there's lots of debugging info but I
could not find any data related with the problem ...

Hope this helps.

Regards,

    André

   ____________________________________________________________________
  /|               __                 | Andre' Ventura Zu'quete        |
 /_|  /|_  _|_ /    / /  _     _|_    | e-mail: Andre.Zuquete at inesc.pt |
|    /-| )(_| (-   /_|_)(_|_)(- | (-  | Phone: +351 213100-395         |
|                         |           | URL: www.gsd.inesc.pt/~avz     |
 ----------------------------------------------------------------------
| INESC (Instituto de Engenharia de Sistemas e Computadores)         __|
| R. Alves Redol 9, 6. 1000 Lisboa, PORTUGAL                        | /
| Fax: +351 213145843                                               |/
 -------------------------------------------------------------------






More information about the Arla-drinkers mailing list