search for: i_file_acl

...ory inode 1785857 (...) Connect to /lost+found? yes Unconnected directory inode 2162689 (...) Connect to /lost+found? yes Unconnected directory inode 3129345 (...) Connect to /lost+found? yes Unconnected directory inode 8601601 (...) Connect to /lost+found? yes Pass 4: Checking reference counts i_file_acl for inode 11 (...) is 536879104, should be zero. Clear? yes i_faddr for inode 11 (...) is 536879104, should be zero. Clear? yes i_fsize for inode 11 (...) is 32, should be zero. Clear? yes Segmentation fault

Hi, I'm using ext3 filesystems in embedded devices (storage is on 512Mb or 1Gb CF cards). A typical development cycle would see the filesystem created on the desktop PC running linux 2.4 (eg. RedHat 9). The CF card would be installed in the hardware and linux 2.4 (eg. Montavista Pro 3.1, on PPC) would boot from the CF. Recently I tried a linux 2.6 desktop (CentOS) for the same task and

...time = 1296464377, i_dtime = 0, i_gid = 1000, i_links_count = 2, i_blocks = 32, i_flags = 528384, osd1 = {linux1 = {l_i_version = 1981}, hurd1 = {h_i_translator = 1981}}, i_block = {193290, 4, 0, 0, 1, 149430439, 1, 3, 149430464, 0, 0, 0, 0, 0, 0}, i_generation = 2854948622, i_file_acl = 0, i_dir_acl = 0, i_faddr = 0, osd2 = {linux2 = { l_i_blocks_hi = 0, l_i_file_acl_high = 0, l_i_uid_high = 0, l_i_gid_high = 0, l_i_reserved2 = 0}, hurd2 = {h_i_frag = 0 ''\000'', h_i_fsize = 0 ''\000'', h_i_mode_high = 0, h_i_uid_high...

Has anyone tried LFS (ie >2G files support) and Ext3 together? Are there good reasons why this should/should not work? I see the RH enterprise kernel patch set specifically does not attempt both lfs and ext3, but the lfs patches themselves touch some reasonably localised parts of ext2, so I would hope (without having dived in there to test), that the ext3 changes would mirror that

Hello-- We have a system where a central server formats removable hard disks, which are then booted in an embedded system running a highly modified RH9. The removable disks themselves contain boot, root, and data filesystems. The problem we've encountered after upgrading to FC3 / kernel 2.6 on the central server is that the 2.4 kernel in the embedded system cannot read the root filesystem,

...; - data = (void *)EXT2_XATTR_IFIRST(ext2_inode) + - entry->e_value_offs; - datalen = entry->e_value_size; - ret = copy_single_xattr(trans, root, objectid, - entry, data, datalen); - if (ret) - goto out; - entry = EXT2_EXT_ATTR_NEXT(entry); - } - } - - if (ext2_inode->i_file_acl == 0) - goto out; - - buffer = malloc(block_size); - if (!buffer) { - ret = -ENOMEM; - goto out; - } - err = ext2fs_read_ext_attr(ext2_fs, ext2_inode->i_file_acl, buffer); - if (err) { - fprintf(stderr, "ext2fs_read_ext_attr: %s\n", - error_message(err)); - ret = -1; - goto out...

...e, uint32_t inr) { inode->mode = IFTODT(e_inode->i_mode); inode->size = e_inode->i_size; @@ -156,6 +156,7 @@ static void fill_inode(struct inode *inode, const struct ext2_inode *e_inode) inode->flags = e_inode->i_flags; inode->file_acl = e_inode->i_file_acl; memcpy(PVT(inode)->i_block, e_inode->i_block, sizeof PVT(inode)->i_block); + PVT(inode)->i_ino = inr; } static struct inode *ext2_iget_by_inr(struct fs_info *fs, uint32_t inr) @@ -169,11 +170,32 @@ static struct inode *ext2_iget_by_inr(struct fs_info *fs, uint32_t inr)...

...i_new_inode = 1; inode->u.ext2_i.i_flags = dir->u.ext2_i.i_flags; if (S_ISLNK(mode)) inode->u.ext2_i.i_flags &= ~(EXT2_IMMUTABLE_FL | EXT2_APPEND_FL); - inode->u.ext2_i.i_faddr = 0; - inode->u.ext2_i.i_frag_no = 0; - inode->u.ext2_i.i_frag_size = 0; - inode->u.ext2_i.i_file_acl = 0; - inode->u.ext2_i.i_dir_acl = 0; - inode->u.ext2_i.i_dtime = 0; inode->u.ext2_i.i_block_group = i; if (inode->u.ext2_i.i_flags & EXT2_SYNC_FL) inode->i_flags |= S_SYNC; diff -ru linux-2.4.3p6/fs/hpfs/inode.c linux-2.4.3p6-aed/fs/hpfs/inode.c --- linux-2.4.3p6/fs/hpfs/...

Hi, I just tried the 2.6.22-r1 candidate to test whether some bug I have hit in the past still exists. I did use 2.6.20.6 so far. So, I have cleanly rebooted to use the new kernel, after the machine came up I tried to mess with the bug, and had to reboot again to play with kernel commandline parameters. Unfortunately, on the next reboot fsck was schedules on my filesystem after 38 clean

Hi, The following patches add support for ext4 and btrfs to PV-GRUB. These patches are taken nearly verbatim from those provided by Fedora and Gentoo. We''ve been using these patches for the PV-GRUB images available in EC2 for some time now with no problems. Changes from v1: - Makefile has been changed to check the exit code from patch - The btrfs patch has been rebased to apply