Very Computer

Quote:> Dieter NJtzel writes:
>  > but kernel 2.4.15-pre7 + preempt + ReiserFS A-N do _NOT_ boot for me.
>  > I've tried it with "old" and "new" (current) N-inode-attrs.patch.
>  > But that doesn't matter.

>  > [-]
>  > IP: routing cache hash table of 8192 buckets, 64Kbytes
>  > TCP: Hash tables configured (established 262144 bind 65536)
>  > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
>  > reiserfs: checking transaction log (device 08:03) ...
>  > Using r5 hash to sort names
>  > ReiserFS version 3.6.25
>  > VFS: Mounted root (reiserfs filesystem) readonly.
>  > Freeing unused kernel memory: 208k freed
>  > "Warning: unable to open an initial console."

> N-inode-attrs.patch uses previously unused field in reiserfs on-disk
> inode structure to store inode attributes. It seems that in some cases
> this field actually contains garbage. It may happen that you have got
> immutable bit for your console device this way.

Hmm, this may be a kernel bug also, in a way.  I don't know if ext2
allows you to set attributes on char/block special files, but if it
does, then the "immutable" attribute should _probably_ apply to
changing the device inode, rather than writing to the device itself.

In any case, it is also a bad thing to leave garbage in unused parts of
on-disk data structs for just this reason, so mkreiserfs should zero
everything that is unused inside allocated structs (and the kernel too,
because reiserfs allocates inode tables dynamically, right?).

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

    I started to write ACL support based on Andreas Grnbacher's patches at
    http://acl.bestbits.at a few months ago. Since there was no decided upon
    format, I stopped development so that I wouldn't leave non-standard
    filesystems in my wake. Once the ACL/EA format/API is finalized, I'll
    probably continue development on it.

    On a more technical note, adding a new item type, such as an
    extended attribute item will cause problems for implementations that
    don't know about them. An idea kicked around a few months ago was to
    simply change the version string so that implementations that don't
    know about ACL support can't mount the new version. "can't mount"
    could conceivably be changed to "can only mount read-only", but certainly
    not read-write, since non-solid items need special handling (every item
    but stat data is non-solid).

    This creates the following scenario:
    * Versions that don't know about the new version string will
      refuse to mount the fs.
    * Versions that know about the new version, but don't implement support
      will be read-only. This is because items get moved during balancing, even
      to un-related items. Knowledge of the inside non-solid items is required
      to move them around. So, even if there is a single ACL on the system, in
      some deep directory, it could affect balancing (cause a panic).
    * Versions that know about the new version, and implement support will
      be read-write.

    I see something along the lines of EXT2's compatibility matrix happening
    here, but due to the inherent incompatibilities, this may not be a prime
    candidate for 2.4 inclusion.

    -Jeff

--
Jeff Mahoney           |   "Bill Gates is a monocle and a Persian cat away

application_pgp-signature_part < 1K Download