On 04/23/2015 06:55 PM, NeilBrown wrote:
By "jbod" I assume you mean "linear array".
You say this happens without any filesystem on the array, yet the stack
traces clearly show ext2 in use.
Maybe some weird interaction is happening between the the filesystem and the
linear array.
But please confirm that the stack trace happened when there was no filesystem
on the array you were testing, and report what filesystems you do have which
use ext2.
Neil --
Yes, I do mean linear array.
At the point of the stack trace, there was no file-system on the linear
2-drive array. The test-jbod-2 script would create the array and then
write directly to /dev/md0. Any evidence of previous existence of a
file-system would have been obliterated by earlier runs copying
/dev/zero everywhere.
The file-systems in use --
-- The rootfs is an initrd file, squashfs, and mounted read-only.
-- An ext3 for configuration and logs is mounted RW on /flash
-- An ext2 using 8MB of RAM is mounted RW on /var
-- The file-server is derived from a much earlier design that required
some RW directories within the root. These entries appear in the mount
command as ext2, but are part of /var (and not separate file systems) --
-- mount --bind /var/hd /hd
-- mount --bind /var/home /home
-- A devtmpfs mounted on /dev, tmpfs on /dev/shm, proc on /proc, sysfs
on /sys, and another mount --bind from within /flash for nfs.
# mount
/dev/root on / type squashfs (ro,relatime)
devtmpfs on /dev type devtmpfs
(rw,relatime,size=1002600k,nr_inodes=250650,mode=755)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
/dev/ram1 on /var type ext2 (rw,relatime,errors=continue)
/dev/ram1 on /hd type ext2 (rw,relatime,errors=continue)
/dev/ram1 on /home type ext2 (rw,relatime,errors=continue)
tmpfs on /dev/shm type tmpfs (rw,relatime)
/dev/sdb1 on /flash type ext3
(rw,noatime,errors=continue,commit=60,barrier=1,data=ordered)
/dev/sdb1 on /var/lib/nfs type ext3
(rw,noatime,errors=continue,commit=60,barrier=1,data=ordered)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
#
> Is there any chance you could use "git bisect" to find out exactly which
> commit introduced the problem? That is the mostly likely path to a
solution.
>
I am not familiar with "git bisect". Would this be similar to
downloading a series of kernel releases from linux-3.3.5 up to 3.18.5
using a binary search to find which release (rather than which commit)
has the problem ?
Thanks
Charles Bertsch
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
