sf...@users.sourceforge.net wrote:
> Here is a patch to confirm ext3's behaviour for linux-2.6.36.1.
> - apply this patch and aufs2.1-36.
> - enable MagicSysRq and CONFIG_AUFS_MAGIC_SYSRQ.
> - build and reboot.
> - run my previous simple script which runs dd, mv and remount. It
> should fail with
Cyanrigger:
> > And we need to fix the target kernel version.
> > When you are ready, please tell me your prefered verion too.
>
> My desired kernel version would be 2.6.36.1.
Hi,
Sorry my late reply.
Here is a patch to confirm ext3's behaviour for linux-2.6.36.1.
- apply this patch and aufs2.1-3
sf...@users.sourceforge.net wrote:
> And we need to fix the target kernel version.
> When you are ready, please tell me your prefered verion too.
My desired kernel version would be 2.6.36.1.
Marcus
--
Increase Visibili
Cyanrigger:
> Yes. You can send me the patches.
> I will setup a faster test environment.
> But I want to think over the problems once - so it may take a little
> time until I respond, ok?
Of course, yes.
And we need to fix the target kernel version.
When you are ready, please tell me your prefer
sf...@users.sourceforge.net wrote:
>
> - and more, maybe...
>
> By the way, if I send you a patch to investigate more, would you test
> it? The patch will be against aufs, vfs or ext3 and do nothing but
> print some messages.
Yes. You can send me the patches.
I will setup a faster test environm
Cyanrigger:
> Actually, I posted that in my last post.
> But I copy it up to here for readabilitys sake:
> http://pastebin.com/b5361Kk5
>
> Here is the rsync-script I use again:
> http://pastebin.com/X4yuqYuk
Thanks.
Currently, I think "remount,ro ext3" should fail as the simple dd script
did, bu
sf...@users.sourceforge.net wrote:
> Cyanrigger:
> > Yes, it is mounted according to /proc/mounts (here is the whole, for
> > your amusement) :
>
> Not satisfied.
I just meant that my /proc/mounts just looks a bit awkward because
there is mounted so much stuff.
> Please add '-v' to remount ext
sf...@users.sourceforge.net wrote:
> Cyanrigger:
> > Yes, it is mounted according to /proc/mounts (here is the whole, for
> > your amusement) :
>
> Not satisfied.
I just meant that my /proc/mounts just looks a bit awkward because
there is mounted so much stuff.
> Please add '-v' to remount ext
Cyanrigger:
> Yes, it is mounted according to /proc/mounts (here is the whole, for
> your amusement) :
Not satisfied.
Please add '-v' to remount ext3 readonly in your rsync script.
cat /proc/mounts after remount ext3 readonly is good too.
J. R. Okajima
-
sf...@users.sourceforge.net wrote:
> > I think 'is busy' is not what you wanted. Should I try it again
> > slightly modified?
>
> 'is busy' is the expected error.
> This behaviour is correct, and fsck reports errors very similarly to
> your rsync case. Did your rsync script really succeed remount
Cyanrigger:
> I have no sudo - I executed it as root.
> This is the output of the script:
> http://pastebin.com/yq7qHxkd
>
> I think 'is busy' is not what you wanted. Should I try it again
> slightly modified?
'is busy' is the expected error.
This behaviour is correct, and fsck reports errors ver
sf...@users.sourceforge.net wrote:
> You may say "cannot remount ext3 readwrite anymore". It is related to
> my question in previous mail.
>
>
> > > > I got another question in my mind.
> > > > At the end of your rsync script,
> > > > mount -o remount,ro ${LOWER_BRANCH}
> > > > Why didn'
Cyanrigger:
> > > > I think it is a problem of your shutdown script.
> > > > Generally any shutdown script executes
> > > > - kill all processes
> > > > - remount / readonly
> > > >
> > > > For the system whose root is aufs, the similar scirpt but more
> > > > work is necessary. In your case,
> >
Hi,
> > sf...@users.sourceforge.net:
> > > > Do you consider this a bug in aufs, though?
> > >
> > > No.
> > > I think it is a problem of your shutdown script.
> > > Generally any shutdown script executes
> > > - kill all processes
> > > - remount / readonly
> > >
> > > For the system whose root
On Sat November 27 2010, sf...@users.sourceforge.net wrote:
>
> sf...@users.sourceforge.net:
> > > Do you consider this a bug in aufs, though?
> >
> > No.
> > I think it is a problem of your shutdown script.
> > Generally any shutdown script executes
> > - kill all processes
> > - remount / readon
sf...@users.sourceforge.net:
> > Do you consider this a bug in aufs, though?
>
> No.
> I think it is a problem of your shutdown script.
> Generally any shutdown script executes
> - kill all processes
> - remount / readonly
>
> For the system whose root is aufs, the similar scirpt but more work is
Cyanrigger:
> No, I made a mistake and made the test with just a "cp", which behaves
> like I said and I assumed rsync would do the same.
> Now I also know what these "--delete-X" parameters of rsync do.
> AFAIK you're right about the behaviour of rsync and your explanation in
> your second-la
sf...@users.sourceforge.net wrote:
> > If I do the same on a pure ext3 system, the inode number of the
> > file is not being changed if I copy new content in it. It is just
> > the case if I do some kind of copy-on-write.
>
> I might misunderstand the behaviour of rsync.
> I thought it operats
>
Cyanrigger:
> > rsync copies the file. the target file is removed but ext3 doesn't
> > release the resources for the file since the inode is still referenced
> > and alive.
> Wow. That really bends my brain.
> You say that the target file is removed at copying. So this is the
> reason why the inod
sf...@users.sourceforge.net wrote:
>
> My English and brain are broken, sorry.
Hehehe ;) I am also not a native english speaker. But I think we'll work
it out.
Nevertheless, you are a wizard :D
> > Here is my guess.
> > - syslogd opens these log files for write.
> > - in the beginning, files exi
My English and brain are broken, sorry.
sf...@users.sourceforge.net:
> Here is my guess.
> - syslogd opens these log files for write.
> - in the beginning, files exist on the lower ext3 only. no on the upper
> tmpfs.
> - aufs opens files on the lower ext3.
> - when syslogd writes to them first
Cyanrigger:
> Here is a listing of the files that are moved with the rsync script.
> When I compare the inode numbers from that files with the ones, fsck
> complains about I found out that they're all log-files.
> (please see the comments in the pastebin link)
>
> http://pastebin.com/uiD6PBTH
>
>
Hi,
I hope it's ok to continue this topic in a new thread, because the old
thread is now a bit uncomfortable to read.
I also come up with some results. I hope that you can help to
interprete them.
Here is a listing of the files that are moved with the rsync script.
When I compare the inode number
Cyanrigger wrote:
> So either my setup (initramfs script) is impossible to work with aufs
> or I activated the wrong aufs options (kernel,mount,/etc/default/aufs)
> or some userspace program interferes (rather unlikely)
> or it's a bug in kernel (ext3 or aufs).
> or some fubar ...
>
> I thi
Cyanrigger wrote:
> The next I will try is to move every single file (or a group) rsync
> would have copied, per hand. And after every transfer I will fsck.
> Wish me luck.
I have tried to copy groups of files instead of the whole tmpfs and
then fsck for errors. I always got errors after copyi
J. R. ,
> Then, does it mean that you run rsync when your system is very idle?
Yes. The system is a very idle one in general. It's just a dumb ppp
router.
I looked at the output of lsof and couldn't see other processes
writing something, during the rsync or the test.
> Cyanrigger:
> > However
Cyanrigger:
> However after this, when the stress-test is over the errors are gone
> (like it was on ext3):
I have tried the similar test to yours on my linux-2.6.31.
The result has no errors.
I may need to test linux-2.6.36.1 (as you did). It will be next week.
-
Cyanrigger:
> So I think that is just a nasty timing problem and is different from my
> original error.
Then, does it mean that you run rsync when your system is very idle?
J. R. Okajima
--
Increase Visibility of Your
Continued from last post,
Now /dev/sda1 being mounted as ext2 I made the rsync test:
- - - - - - - -
#!/bin/bash
UPPER_BRANCH='/mnt/rw_root/'
LOWER_BRANCH='/mnt/ro_root/'
mount -o remount,udba=notify /
mount -o remount,rw ${LOWER_BRANCH}
case $UPPER_BRANCH in
*/)
;;
J.R.,
> Deleted inode 53 has zero dtime. Fix? no
> Block bitmap differences: -615
> Inode bitmap differences: -53
> Directories count wrong for group #0 (47, counted=46).
>
> I don't know these messages are related to your problem, but I'd
The one error I got was huma
Cyanrigger:
> As you can see in the listing below, I let it run for 7 loops total.
> Is this enough to make a statement?
> The script works - whenever the check is running I can see on a
> different shell with "watch -n 1 ls /mnt/ro_root/test/" that no changes
> are being made.
> He runs into "mou
Hello J. R.,
> The name of RANDOM files are all numbers, right?
That's right.
> Ah, the two lines in the foreground script should be connected by &&,
Ah ok. Tried again after I made this change.
As you can see in the listing below, I let it run for 7 loops total.
Is this enough to make a stateme
Cyanrigger:
> > do dd if=/dev/zero of=$f bs=$((($RANDOM % 8) + 16))
> I corrected $f to $i. I guess this was a typo...
Sorry.
> The general behaviour is:
> When I start the stresstest script ( I positioned it in a directory
> on /mnt/ro_root/test/ ) I can see a few processes with "ps" that
Hello J. R. ,
> do dd if=/dev/zero of=$f bs=$((($RANDOM % 8) + 16))
I corrected $f to $i. I guess this was a typo...
Ok, I tried the procedure you described running the check in the
foreground and the stress test in the background.
The result is a bit puzzling. I try my best to describe
Cyanrigger:
> What do you exactly mean by stress test? Just copying files from
> somewhere - maybe from /dev/zero to /dev/sda1 (which is my
> ext3) with various dd's ?
Filesystem stress test is something like this.
Of course, you can customize whatever you like.
#!/bin/bash
Creat()
{
fo
Am Wed, 24 Nov 2010 23:46:55 +0900
schrieb sf...@users.sourceforge.net:
Hello J. R.
Thanks for your quick response!
> Hmm, let's make sure first that readonly re-mounted ext3 is always
> safe.
> If you have some filesystem stress test, then
What do you exactly mean by stress test? Just copying
Hello Marcus,
Cyanrigger:
> fsck -nf /dev/sda1
:::
> Warning! /dev/sda1 is mounted.
:::
Hmm, let's make sure first that readonly re-mounted ext3 is always safe.
If you have some filesystem stress test, then
- run it for ext3 in background with ignoring all errors
- run this scri
Hi,
I have a problem with aufs used as root of the filesystem. I know
that there are similar posts. I have read them, but since I have the
latest version of aufs and a fresh kernel I wonder what the problem
might be...I have f.e. not tried to play with ?plinks? yet, because I
don't understand the
38 matches
Mail list logo
