Thread: [Aoetools-discuss] File System Failure after Unmount
Brought to you by:
ecashin,
elcapitansam
From: Stephen B. <sbr...@gm...> - 2007-01-08 16:09:40
|
Hi There, I hope this is the correct forum to address what is possibly a newbie problem (or a misunderstanding of the fundamentals). I apologise if it has been covered previously but I did my best to search everything I could find about the following issue. I seem to be able to mount a partition once and that's it. After that its unusable. To start I create the XFS filesystem on /dev/sdb1 (this filesystem is NOT mounted locally, purely here for AoE) and export with vblade. |root@aoe-server:~# mkfs.xfs -f /dev/sdb1 |meta-data=/dev/sdb1 isize=256 agcount=8, agsize=125004 blks | = sectsz=512 attr=0 |data = bsize=4096 blocks=1000032, imaxpct=25 | = sunit=0 swidth=0 blks, unwritten=1 |naming =version 2 bsize=4096 |log =internal log bsize=4096 blocks=2560, version=1 | = sectsz=512 sunit=0 blks |realtime =none extsz=65536 blocks=0, rtextents=0 |root@aoe-server:~# vblade 0 9 eth0 /dev/sdb |pid 2562: e0.9, 16384000 sectors O_RDWR Moving to the intended client I do a aoe-stat to verify the block device is available. and proceed to mount and write to it (successfully). |root@aoe-client:/mnt/etherdrive# aoe-stat | e0.9 8.388GB eth0 up |root@aoe-client:/mnt/etherdrive# mount /dev/etherd/e0.9p1 /mnt/etherdrive/1 |root@aoe-client:/mnt/etherdrive# df |Filesystem 1K-blocks Used Available Use% Mounted on |/dev/sda1 3580256 2335840 1244416 66% / |/dev/etherd/e0.9p1 3989888 312 3989576 1% /mnt/etherdrive/1 |root@aoe-client:/mnt/etherdrive# echo "Test" > /mnt/etherdrive/1/test.txt |root@aoe-client:/mnt/etherdrive# cat /mnt/etherdrive/1/test.txt |Test All is good right? Yes, but now comes the interesting part. |root@aoe-client:/mnt/etherdrive# umount /mnt/etherdrive/1 |root@aoe-client:/mnt/etherdrive# mount /dev/etherd/e0.9p1 /mnt/etherdrive/1 |mount: No such file or directory >From this point on I can no longer mount /dev/etherd/e0.9p1 (mounting /dev/sdb1 locally on the server gives the same result). The result is the same if I start off by creating the filesystem via /dev/etherd/e0.9p1 in the first case or export /dev/sdb1 directly (as opposed to /dev/sdb root device as above). /dev/etherd/err shows nothing however dmesg has the following confusing output (after the successful and subsequent failed mount attempts). |aoe: e0.9: setting 1024 byte data frames on eth0 |aoe: 000c290a6311 e0.9 v400c has 16384000 sectors | etherd/e0.9: p1 p2 |Filesystem "etherd/e0.9p1": Disabling barriers, not supported by the underlying device |XFS mounting filesystem etherd/e0.9p1 |Ending clean XFS mount for filesystem: etherd/e0.9p1 |FAT: bogus number of reserved sectors |VFS: Can't find a valid FAT filesystem on dev etherd/e0.9p1. |GFS2: not a GFS2 filesystem |GFS2: Unrecognized block device or mount point /dev/etherd/e0.9p1<4>GFS2: gfs2 mount does not exist Few details for those that made it this far: Linux: 2.6.19.1 #2 SMP i686 pentium4 i386 GNU/Linux (quick plain slack11 install) vblade: 20317 vblade-14.tgz aoetools: 20040 aoetools-13.tar.gz If anyone could shed some light on what I have done/not done/missed/etc I would be thrilled. I have done my best to resolve this myself however I have so far been unsuccessful. I hope to get it working soon, then I can move onto getting GPFS or OCFS up and running. Many thanks in advance. -- - Cheers Stephen |
From: Sam H. <sa...@co...> - 2007-01-08 17:52:27
|
Hello Stephen, > I hope this is the correct forum to address what is possibly a newbie > problem (or a misunderstanding of the fundamentals). I apologise if it has > been covered previously but I did my best to search everything I could find > about the following issue. I seem to be able to mount a partition once and > that's it. After that its unusable. No worries. Searching the history of the list @ gmane is good practice before posting to the list, but we're not as militant as other folks. >>From this point on I can no longer mount /dev/etherd/e0.9p1 (mounting > /dev/sdb1 locally on the server gives the same result). The result is the > same if I start off by creating the filesystem via /dev/etherd/e0.9p1 in the > first case or export /dev/sdb1 directly (as opposed to /dev/sdb root device > as above). Try updating to the standalone driver available on our website. This sounds like an issue that has been recently resolved. Search the list history for "scatter gather" for a full discussion. http://www.coraid.com/support/linux/ Cheers, Sam |
From: Ed L. C. <ec...@co...> - 2007-01-08 18:32:19
|
On Mon, Jan 08, 2007 at 12:46:57PM -0500, Sam Hopkins wrote: ... > Try updating to the standalone driver available on our website. This > sounds like an issue that has been recently resolved. Search the list > history for "scatter gather" for a full discussion. > > http://www.coraid.com/support/linux/ By the way, there are two issues involved, and I thought I'd mention that there is a bugfix for the aoe driver that has made its way into Linus Torvalds' kernel tree, and I just got word from the maintainers of the stable kernel that it should be in the next stable release of 2.6.19.x. To recap a bit, that fix affects systems using AoE over network interfaces that don't support scatter gather. On such systems, though, if you use an aoe driver with that fix (like aoe6-42), a certain behavior of XFS will result in kernel panics. http://article.gmane.org/gmane.linux.kernel/476989 While this discussion continues, and until the real solution is discovered, we have provided a workaround in aoe6-43 that's based on a patch that showed up here on this list recently. -- Ed L Cashin <ec...@co...> |
From: Stephen B. <sbr...@gm...> - 2007-01-09 02:21:23
|
Thanks All, The feedback was great. I removed the bundled 2.6.19.1 aoe module and updated to aoe6-43. Things seem to be working now however I am curious about the XFS kernel panics mentioned earlier since I have chosen to move forward to 6-43 rather then back to 6-22 as was suggested. Does my risk only lie with the use of XFS or does the scatter gather issue affect other file systems you are aware of. I have no issue avoiding XFS as I fully intend to run some form of multi platform cluster file system (if I can find one that supports r/w on nix/win). PS. The source of the scatter gather issue in my case could be the VMWare ESX lance network adapter and virtual switch that have been using to play with aoe. It may not correctly support the features in use by aoe. Thanks for the quick response. - Stephen On 09/01/07, Stephen Brennan <sbr...@gm...> wrote: > > Thanks All, > > The feedback was great. I removed the bundled 2.6.19.1 aoe module and > updated to aoe6-43. Things seem to be working now however I am curious about > the XFS kernel panics mentioned earlier since I have chosen to move forward > to 6-43 rather then back to 6-22 as was suggested. Does my risk only lie > with the use of XFS or does the scatter gather issue affect other file > systems you are aware of. I have no issue avoiding XFS anyway as I fully > intend to run some form of multi platform cluster file system (if I can find > one). > > PS. The source of the scatter gather issue in my case could be the VMWare > ESX lance network adapter and virtual switch that have been using to play > with aoe. It may not correctly support the features in use by aoe. > > Thanks for the quick response. > - Stephen > > On 09/01/07, Ed L. Cashin <ec...@co...> wrote: > > > > On Mon, Jan 08, 2007 at 12:46:57PM -0500, Sam Hopkins wrote: > > ... > > > Try updating to the standalone driver available on our website. This > > > sounds like an issue that has been recently resolved. Search the list > > > history for "scatter gather" for a full discussion. > > > > > > http://www.coraid.com/support/linux/ > > > > By the way, there are two issues involved, and I thought I'd mention > > that there is a bugfix for the aoe driver that has made its way into > > Linus Torvalds' kernel tree, and I just got word from the maintainers > > of the stable kernel that it should be in the next stable release of > > 2.6.19.x. > > > > To recap a bit, that fix affects systems using AoE over network > > interfaces that don't support scatter gather. On such systems, > > though, if you use an aoe driver with that fix (like aoe6-42), a > > certain behavior of XFS will result in kernel panics. > > > > http://article.gmane.org/gmane.linux.kernel/476989 > > > > While this discussion continues, and until the real solution is > > discovered, we have provided a workaround in aoe6-43 that's based on a > > patch that showed up here on this list recently. > > > > -- > > Ed L Cashin < ec...@co...> > > > > > > -- > - Cheers > Stephen -- - Cheers Stephen |
From: Sam H. <sa...@co...> - 2007-01-09 14:51:08
|
Hey Stephen, > The feedback was great. I removed the bundled 2.6.19.1 aoe module and > updated to aoe6-43. Things seem to be working now however I am curious about > the XFS kernel panics mentioned earlier since I have chosen to move forward > to 6-43 rather then back to 6-22 as was suggested. Does my risk only lie > with the use of XFS or does the scatter gather issue affect other file > systems you are aware of. I have no issue avoiding XFS as I fully intend to > run some form of multi platform cluster file system (if I can find one that > supports r/w on nix/win). The aoe6-43 driver includes a workaround for the XFS problem so there's no reason to avoid it particularly. The problem is supposedly possible in other filesystems, though we've not yet seen it. > PS. The source of the scatter gather issue in my case could be the VMWare > ESX lance network adapter and virtual switch that have been using to play > with aoe. It may not correctly support the features in use by aoe. Good to know. Cheers, Sam |