On Mon, Aug 26, 2013 at 06:40:49PM +0800, Liu Yuan wrote: > On Mon, Aug 26, 2013 at 09:47:41AM +0000, 周鹏 wrote: > > >> It can know from the log that "volume_do_sync" will do > > >> CREATE_AND_WRITE_OBJ and then write something to the cache. > > >> In order to further confirmation, the source code is really to do so. > > >> But when and how did the vm became Read-only file system, i can not > > >> understand.So please help me to analyze the cause,thanks. > > > > >If it is snapshot, it is read-only vdi. > > > > >> BTW,when i test the sheepdog, i often meet the vm became Read-only.So > > >> another question, what can cause a read_only? > > > > > > >Please use latest stable-0.7 or stable-0.6 branch and report problems if > > >any. > > > > Yeah, i have updated the sheepdog to version 0.7.1_1_g66102e5. > > The same problem still exists. > > Under the path of "/home/centos6/root", i excute: > > > > [root@sheep-dell root]# echo aa>test.txt > > -bash: test.txt: Read-only file system > > > > At the same time, sheepfs printed: > > volume_do_sync(306): failed to flush vdi 7c7833 > > volume_do_sync(306): failed to flush vdi 7c7833 > > Could you show me 'dog vdi list'? > > I guess you were mounting a read-only vdi. I have tried write something into a > writeable vdi (either clone or a normal vdi) with success. > > > > > gataway log: > > > > Aug 26 17:33:47 DEBUG [main] client_handler(786) 1, rx 0, tx 3 > > Aug 26 17:33:47 DEBUG [main] finish_rx(590) 48, 127.0.0.1:49869 > > Aug 26 17:33:47 DEBUG [main] queue_request(347) WRITE_OBJ, 1 > > Aug 26 17:33:47 DEBUG [gway 13163] do_process_work(1334) 3, > > 7c78330000029d, 1 > > Aug 26 17:33:47 DEBUG [gway 13163] gateway_forward_request(267) > > 7c78330000029d > > Aug 26 17:33:47 DEBUG [gway 13163] sockfd_cache_get_long(372) > > 192.168.10.41:7010, idx 0 > > Aug 26 17:33:47 DEBUG [gway 13163] sockfd_cache_get_long(372) > > 192.168.10.45:7010, idx 0 > > Aug 26 17:33:47 DEBUG [gway 13163] sockfd_cache_get_long(372) > > 192.168.10.47:7010, idx 0 > > Aug 26 17:33:47 DEBUG [gway 13163] gateway_forward_request(320) nr_sent 3, > > err 0 > > Aug 26 17:33:47 DEBUG [gway 13163] wait_forward_request(195) 0, revents 1 > > Aug 26 17:33:47 DEBUG [gway 13163] sockfd_cache_put_long(406) > > 192.168.10.41:7010 idx 0 > > Aug 26 17:33:47 DEBUG [gway 13163] write_info_update(115) 3, 0 > > Aug 26 17:33:47 DEBUG [gway 13163] wait_forward_request(195) 0, revents 1 > > Aug 26 17:33:47 DEBUG [gway 13163] sockfd_cache_put_long(406) > > 192.168.10.45:7010 idx 0 > > Aug 26 17:33:47 DEBUG [gway 13163] write_info_update(115) 2, 0 > > Aug 26 17:33:47 DEBUG [gway 13163] wait_forward_request(195) 0, revents 1 > > Aug 26 17:33:47 DEBUG [gway 13163] sockfd_cache_put_long(406) > > 192.168.10.47:7010 idx 0 > > Aug 26 17:33:47 DEBUG [gway 13163] write_info_update(115) 1, 0 > > Aug 26 17:33:47 DEBUG [main] client_handler(786) 4, rx 0, tx 3 > > Aug 26 17:33:47 DEBUG [main] finish_tx(677) connection from: 48, > > 127.0.0.1:49869 > > The log didn't report anything wrong.
Oops, I noticed that there is a fix for latest sheepfs. Could you try latest master branch to see if problem fixed? Then we can fix stable-0.7 and stable-0.6 Thanks Yuan -- sheepdog mailing list [email protected] http://lists.wpkg.org/mailman/listinfo/sheepdog
