I'm having some problems moving a file system back and forth between an
FC3 box and some linux-2.4 based systems, (one rh9, one embedded).
I have built a small ext3 file system on a USB solid state device. I've
populated it with:
cd filesystem
touch foo
ln -s foo bar
When I move the USB device to a linux-2.4 system, the symlink can't be
read and instead produces an io error during "ls".
Removing the symlink and remaking it manually on my linux-2.4 box
results in a symlink that can be read.
I can only find one significant difference between the symlink created
on my FC3 and the symlink created on my 2.4 box. Here it is:
# ls -las
1 drwxr-xr-x 3 root root 1024 Jan 1 00:01 .
1 drwxr-xr-x 15 root root 1024 Jan 1 00:00 ..
1 lrwxrwxrwx 1 root root 3 Jul 21 2005 barls:
ls:./bar: Input/output error
0 lrwxrwxrwx 1 root root 3 Jan 1 00:01 baz -> foo
1 -rw-rw-r-- 1 root root 0 Jul 21 2005 foo
12 drwx------ 2 root root 12288 Jul 21 2005 lost+found
"bar" was created on my FC3 and claims to be using 1 disk block.
"baz" was created on my 2.4 box and claims to be using zero.
.../linux-src/Documentation/filesystems/ext2.txt has this jewel:
Symbolic links are also filesystem objects with inodes. They deserve
special mention because the data for them is stored within the inode
itself if the symlink is less than 60 bytes long. It uses the fields
which would normally be used to store the pointers to data blocks.
This is a worthwhile optimisation as it we avoid allocating a full
block for the symlink, and most symlinks are less than 60 characters long.
This suggests that the symlink built on my FC3 is erroneous.
To double check...
root@xxxxxxxxxxxxxxx> PAGER=cat debugfs -w /dev/sda1
debugfs 1.36 (05-Feb-2005)
debugfs: ls -l
2 40755 (2) 0 0 2048 21-Jul-2005 15:21 .
2 40755 (2) 0 0 2048 21-Jul-2005 15:21 ..
11 40700 (2) 0 0 12288 21-Jul-2005 15:01 lost+found
12 100664 (1) 0 0 0 21-Jul-2005 15:02 foo
13 120777 (7) 0 0 3 21-Jul-2005 15:21 bar
14 120777 (7) 0 0 3 31-Dec-1969 16:01 baz
0 0 (0) 0 0 0
debugfs: bmap <13> 0
7303014
debugfs: bmap <13> 1
0
debugfs: icheck 7303014
Block Inode number
7303014 <block not found>
debugfs: stat <13>
Inode: 13 Type: symlink Mode: 0777 Flags: 0x0 Generation:
3072114842
User: 0 Group: 0 Size: 3
File ACL: 4634 Directory ACL: 0
Links: 1 Blockcount: 2
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x42e02001 -- Thu Jul 21 15:21:53 2005
atime: 0x42e02001 -- Thu Jul 21 15:21:53 2005
mtime: 0x42e02001 -- Thu Jul 21 15:21:53 2005
Fast_link_dest: foo
debugfs: stat <14>
Inode: 14 Type: symlink Mode: 0777 Flags: 0x0 Generation:
3710531765
User: 0 Group: 0 Size: 3
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 0
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x00000040 -- Wed Dec 31 16:01:04 1969
atime: 0x42e01cf5 -- Thu Jul 21 15:08:53 2005
mtime: 0x00000040 -- Wed Dec 31 16:01:04 1969
Fast_link_dest: foo
Again, this appears to be erroneous, since the first "block" appears to
be a bogus value, which would make sense if the "fast link dest" were
interpreted incorrectly.
If I manually force the block count to zero, fsck complains and "fixes"
it. However, if I force the block count to zero and immediately move
the device to the 2.4 box, the link works.
Can anyone explain to me what's going on here? Or better, how to create
a file system on FC3 that can be read and used on a linux-2.4 box?
--rich
