Hello Keith,
Keith Erikson:
> Hi I have this situation
> /aufs = /rw1 + /rw2 + /ro+wh
> where /rw1 is 90% empty , /rw2 is 86% full and has directory structure
> Directory/SubD1/subdir2/file , /ro+wh has a different set of directories
> Does copyup work if subdir2 does not exist and cre
o news
- unlink(2) on NFS has not fired FS_DELETE event (because of
silly-rename which is NFS specific behaviour).
Now (since linux-3.15-rc1), NFS fires the event by itself (instead of
VFS). And aufs begins supporting this event.
J. R. Okajima
- auf
Hello Haider,
"Haider Khan -X (haidekha - TATA CONSULTANCY SERVICES LIMITED at Cisco)":
> - We are using thinking of using aufs version 1 because we are cu=
> rrently using Red Hat, CEL 5.5, Linux kernel 2.6.18. It is the only one th=
> at is compatible.
> Please let us know of any kno
"Haider Khan -X (haidekha - TATA CONSULTANCY SERVICES LIMITED at Cisco)":
> I not able to access any of the repositories listed in http://aufs.sourcefo=
> rge.net/. I tried both set: git URL's and the http URL's
I have just tried and succeeded.
I'd suggest you to try again.
J. R. Okajima
---
"Haider Khan -X (haidekha - TATA CONSULTANCY SERVICES LIMITED at Cisco)":
> How do I access all release-note-mails from aufs-users ML?
For example,
- view one of "aufs3 GIT release" on SourceForge
- click "View entire thread" at the bottom of a single message, and you
can get all same-titled m
Hello Nikolay,
Nikolay Pertsev:
> I am wondering if aufs tmpfs memory leak was fixed.
I don't think it "memory leak."
> It was mentioned in the mail list on November 07, 2012
And the story continued to the next Jan... and Sep 2013 when I
introduced a new logic to trucate XINO files.
> And t
Hello Justin,
"Justin (jlec)":
> I also can reproduce the +4k problem with the procedure described here
> http://serverfault.com/q/445445/145512 and linux-3.13.3 + current aufs
> development HEAD.
>
> So, what is the problem now? Is this by design or is this still a bug?
The answer from me is es
"Justin (jlec)":
> One interesting observation I made was that very rapid creation/deletion
> doesn't show this effect, but a repeat rate of 1/10sec or so, does.
It depends on how tmpfs(including VFS) allocates and frees the blocks
(inodes), I guess.
Of course, the workload on your system will be
Nikolay Pertsev:
> AUFS is being used to join some partitions with tmpfs in order to make them
> writable. Here is a test of creating file on big partition (/home/user):
:::
> Used block grew from 325188 to 325192. Space is not freed after file
> deletion. So this makes me to believe it is
Nikolay Pertsev:
> Apparently I can confirm both of the statements. The problem was discovered
> only because those 4 block are never reused. As I mentioned I have a
> completely diskless system. One day I found bunch of messages in my log
> file:
>
> Apr 14 03:40:01 plc-comm kernel: [3212661.0418
Nikolay Pertsev:
> Thank you very much. And yes, I am interested in the patch. Will be great
> to receive it.
Please try this.
This patch manages the assignment of the inode numbers on tmpfs. By
specifying a new mount option "ino", tmpfs assigns the lowest unused
number for a new inode within the
Nikolay Pertsev:
> dmesg reported "aufs au_opts_parse:1155:mount[2760]: unknown option ino"
>
> Could you help me to see what did I do wrong?
The patch and "ino" option are for TMPFS instead of aufs.
Specify "ino" when you mount tmpfs.
J. R. Okajima
"Haider Khan -X (haidekha - TATA CONSULTANCY SERVICES LIMITED at Cisco)":
> In the meantime I have run into another issue with aufs1 testing which I th=
> ought I would give you a heads up on and also request for your help. That =
> is while I am trying to reproduce that issue and investigate it
Nikolay Pertsev:
> Well, I have positive feedback. I booted patched system ( with "ino" option
> for TMPFS ) yesterday shortly after your last response to me. System worked
> through the night and free disk space on aufs partition remains on same
> level. It does not disappear anymore:
Glad to se
Nikolay Pertsev:
> I see what you mean. Am I safe if I do not umount tmpfs? Because in my
> scenario tmpfs is mounted only once in initrd and after that it is never
> umounted.
Then the missing free won't be a problem for you.
But I think "trunc_xino" is safer currently.
J. R. Okajima
"Haider Khan -X (haidekha - TATA CONSULTANCY SERVICES LIMITED at Cisco)":
> So again back to my original question. Why the mention of NFS in the error=
> message? Any guesses?
It means something unmatched in dcache (or icache) is detected.
That is only I can say about ESTALE.
As you might know
Hello Matthew,
Matthew Riley:
> I've hit an instance of a bug that was hypothesized here:
> http://sourceforge.net/p/aufs/mailman/aufs-users/thread/20120723152336.GB1894%40decadent.org.uk/
>
> The LSM called by security_mmap_file in aufs_mmap can attempt to take
> mmap_sem, in which case the thre
Matthew Riley:
> The LSM called by security_mmap_file in aufs_mmap can attempt to take
> mmap_sem, in which case the thread deadlocks. The particular offender
> here is IMA, which ends up calling audit_log_task_info, which tries to
> get mmap_sem here:
Would you tell me the kernel version you are
Matthew Riley:
> I'm using Ubuntu 14.04, so 3.13 kernel.
Thanks.
But I've found ima, especially with the kernel parameter "ima_tcb" never
work on my system.
I am using
- debian
- sysvinit-utils pkg is installed
and
- boot with specifying "ima_tcb"
- sysvinit-utils contains /sbin/startpar ("sta
sf...@users.sourceforge.net:
> In other words, O_DIRECT and IMA don't cowork, at least with "ima_tcb".
> It surely cause a deadlock.
:::
> By the way, are you specifying "ima_tcb", or do you have a
> config/customize file for ima? If you have, would you post the file
> here?
I've found a
Matthew Riley:
> The IMA policy includes this line, which is probably of interest here:
> audit func=FILE_MMAP mask=MAY_EXEC
I see.
But isn't it func=MMAP_CHECK?
Anyway, I hope you won't mind dropping security_mmap_file() call in
aufs_mmap() for the branch-fs file.
security_mmap_file() for the a
Nikolay Pertsev:
> Do you have any estimate on when you would be able to create fix for this?
> The results from patch you have already made are wonderful and it will be
> really great to have this patch fully working.
Do you mean you prefer the patch for tmpfs than "trunc_xino" option?
If so, i
Nikolay Pertsev:
> I thought it is better because you wrote: "I hope this patch will be more
> effective than aufs "trunc_xino" option."
Here I meant "how good to your problem" by the word "effective".
Note that your problem is about space instead of time.
- "trunc_xino" reduces the number of con
o bugfix
- stop calling security_mmap_file() again, reported by Matthew Riley.
I have a plan to add two new patches in aufs release. One is for vfs and
the other is for tmpfs. Both are related to the inode-number assignment.
Hopefully they will appear in a few weeks.
J. R. Okajima
-
o news
- in aufs3-standalong.git, introduce two new patches, vfs-ino.patch and
tmpfs-ibitmap.patch.
aufs3-loopback.patch has existed since many years before, but not
described. Other two patches are introdued by the neighbourhood of
this commit.
There several other patches in aufs
Nikolay Pertsev:
> Do you have any estimate on when you would be able to create fix for this?
> The results from patch you have already made are wonderful and it will be
> really great to have this patch fully working.
I have just made this week's Monday GIT release.
Try tmpfs-ibitmap.patch in au
o bugfix
- minor bugfix, correct error value in link(2)
o news
- begin supporting O_TMPFILE for aufs3.11 and later
J. R. Okajima
- aufs3-linux.git#aufs3.9..aufs3.10 branch
aufs: tiny, au_qstreq to compare two qstr
aufs: tiny, no msg in spinlo
Hello Sergey,
Sergey Korshunoff:
> If we make a new file in aufs which is hard link to the file in
> rr-branch then that branch can't be removed from aufs. Even if we
> remove such hard link - this don't help. Why? If we check changes
Because aufs keeps the information about the file which has e
Sergey Korshunoff:
> PS: current behavior for a hard links don't looks like a natural way.
> For me a more natural mode
> to handle a hard link is to copy up a source file and then make a hard
> link to it. I guess
> no auplink or mount.aufs are needed for this mode.
It is difficult to find the h
Sergey Korshunoff:
> Suppose all hard links don't cross a branch
> We don't need to search anothers when
> case 1) a inode count of original file is 1 (no hard links).
> case 2) often program overrides all hadlinks. as gcc-config do
> case 3) when we do something with a file whose inode was copied
o news
- in aufs3-standlone.git, rename tmpfs-ibitmap.patch to tmpfs-idr.patch.
these patches are refined.
J. R. Okajima
- aufs3-linux.git
aufs: rename tmpfs-ibitmap.patch to tmpfs-idr.patch
- aufs3-standalone.git
ditto
- aufs-util.git
none
Hello Guan,
Guan Xin:
> The new (3.12.x-20140609) aufs introduced this warning.
> Don't know if it is serious or not.
>
> [ 39.235011] [ cut here ]
> [ 39.235023] WARNING: CPU: 1 PID: 1320 at lib/idr.c:527
> idr_remove.part.6+0x1fb/0x200()
> [ 39.235025] idr_remove c
Guan Xin:
> The new (3.12.x-20140609) aufs introduced this warning.
> Don't know if it is serious or not.
>
> [ 39.235011] [ cut here ]
> [ 39.235023] WARNING: CPU: 1 PID: 1320 at lib/idr.c:527
> idr_remove.part.6+0x1fb/0x200()
> [ 39.235025] idr_remove called for id=
Hello Jeremy,
Jeremy Lin:
> I'm looking to use the 'fallocate' command under an aufs mount (within a
> Docker container), but this doesn't seem to work currently. Is there any
> technical reason that the fallocate() syscall isn't available from aufs (on
> backing filesystems that support that sys
Nikolay Pertsev:
> Hopefully more data about this bug will enable you to resolve it faster.
> Also let me know if you want me to test something or if you need more data.
Thanks for the offer.
I will ask you to test but I am not sure when it will happen.
I think I should dive into IDR module.
J.
Nikolay Pertsev:
> Hopefully more data about this bug will enable you to resolve it faster.
> Also let me know if you want me to test something or if you need more data.
I cannot reproduce the problem.
- using aufs3.9 and aufs3.12.x (linux-3.12.7)
- with and without aufs
- create more than a mill
Jeremy Lin:
> I'm looking to use the 'fallocate' command under an aufs mount (within a
> Docker container), but this doesn't seem to work currently. Is there any
> technical reason that the fallocate() syscall isn't available from aufs (on
> backing filesystems that support that syscall, of course)
Guan Xin:
> mach-1) Is an Intel Core 2 Duo, has CONFIG_MCORE2=y, two squashfs
> images on an ext4;
>
> mach-2) Is an Intel Core Duo, has CONFIG_MPENTIUMM=y but otherwise the
> same config as 1, two squashfs images on tmpfs.
>
> This problem only happens to the mach-1.
Then we have two options as
Guan Xin:
> Built with CONFIG_M686=y, same problem.
> Run memtest86+, no error.
Ok, thanks.
Guan, Nikolay, would you test this patch manually for mm/shmem.c?
It may produce a new warining once.
ino = idr_alloc(&sbinfo->idr, inode, 2, INT_MAX, GFP_NOFS);
if (ino
Nikolay Pertsev:
> I tested it. I got the following in my dmesg output:
Thanks.
Confirmed no progress...
J. R. Okajima
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most
Guan Xin:
> Didn't see the new warning after reboot to the patched kernel ...
> Still the same error messages as before.
Thanks guys.
When you have time, please test this too.
You don't have to hurry since I am going to sleep. It is midnight in my
timezone now.
simple_xattrs_free(&info
Nikolay Pertsev:
> Also notice that id values in at least first 9 error messages are products
> of multiplication of number 32768.
>
> In my case I have only 3 error messages and ids are 32768, 65537 and 98304
> which is the same pattern.
Please apply this too and let's see how many times will th
> Please apply this too and let's see how many times will the message
> printed for the same inode-number.
Ah!
please replace 0x8000 by 0x08000.
J. R. Okajima
--
HPCC Systems Open Source Big Data Platform from LexisNex
Nikolay Pertsev:
> Ok, so here it is.
>
> http://pastebin.com/nHacTb7f
Let me make sure.
Didn't you forget applying the patch against mm/shmem.c:shmem_get_inode()?
Didn't it print anything at all?
If it is true, this is a very interesting discovery.
Next time I send you a debug patch, I will con
Jeremy Lin:
> I applied your patch to the 3.13.0-29-generic kernel on Ubuntu 14.04. I ran
> some tests with /usr/bin/fallocate in a Docker 1.0 container, using 1-5 GB
> files. Everything seems to work fine. In particular, when the Docker
> storage is on an ext4 partition, fallocate works as expect
Nikolay Pertsev:
> I did patch both functions. For clarity I uploaded my shmem.c, so you can
> see full content of the file which was used for last compilation:
>
> http://pastebin.com/2qW35Gyv
Confirmed.
> > Didn't it print anything at all?
>
> It did. In this output which I sent in my last e-
o news
- branch aufs3.15 is created
- there seems to exist a problem in tmpfs-idr.patch in
aufs3-standalone.git. I am still investigating with Nikolay Pertsev
and Guan Xin.
- aufs will start supporting fallocate(2) systemcall in next release.
o pre-announce
I have a plan to remove CONFIG_AU
Nikolay Pertsev:
> Notice, how shmem_evict_inode outputs only 3 first times.
> And... You right, I do not see anything from shmem_get_inode()...
That is a mystery.
Anyway here is a new and consolidated patch. Apply this after all aufs
patches you use and tmpfs-idr.patch. In other words, revert all
Nikolay Pertsev:
> I am sorry, but when I tried to patch I got following result (Hunk #4
> FAILED at 1161.):
Ah, I forgot that you are 3.14. The base of the debug patch is 3.12.x.
> If I understand correctly there should be function static void
> shrink_dcache_for_umount_subtree(struct dentry *
Guan Xin:
> With your new patch the dmesg looks much more tidy. Relevant messages:
Thanks.
Let me make sure.
> [ 158.069589] X[1287]:dentry_iput:339: SYSV f500f000 i32768
> 0100777 f46570ac
> [ 158.070099] X[1287]:shmem_evict_inode:660: f500f000, i32768, 0100777
> f46570ac
::
Guan Xin:
> With your new patch the dmesg looks much more tidy. Relevant messages:
Additional questions.
- Is CONFIG_HUGETLBFS enabled for your kernel?
- Did Xserver start before mounting aufs?
J. R. Okajima
--
HPCC Sy
Guan Xin:
> With your new patch the dmesg looks much more tidy. Relevant messages:
>
> [ 158.069589] X[1287]:dentry_iput:339: SYSV f500f000 i32768
> 0100777 f46570ac
I think I cound find the root cause now.
It is SysV IPC and shmget(2) changes the inode number illegally.
Hmm, I need to f
sf...@users.sourceforge.net:
> I think I cound find the root cause now.
> It is SysV IPC and shmget(2) changes the inode number illegally.
> Hmm, I need to find a new work-around...
Guan, Nikolay,
Please test this patch which tries fixing the problem while previous
patches try finding it.
The nece
Guan, Nikolay,
Thank you for your repeating tests.
Here are refined ones, 3.12.x.patch and 3.14.patch.
Please test.
- kernel source
- aufs source
- this patch
Note: you need to revert tmpfs-idr.patch.
> From: Nikolay Pertsev
:::
> Patching file ip
Nikolay Pertsev:
> So, as Guan said - I tried to include to the task_mmu.c - and
> it worked.
I see. My fault. Sorry.
> One thing I noticed (not sure if it is related to our problem) - every time
> I kill X server I get following error:
>
> [ 206.074567] mtrr: no MTRR for e000,800 foun
John Wei:
> I am new to aufs or overlayfs. While studying the design of warden of
> cloudfoundry, the document says that warden was using aufs, then switched
> to overlay starting ubuntu 12. There is no wording on the reason of the
> switch.
Ubuntu declared that they would discard aufs several ye
sf...@users.sourceforge.net:
> I'd ask you one more tests.
> Here is a new tmpfs-idr.patch for next aufs release. It is much more
> simplified.
Thank you very much.
New tmpfs-idr.patch will be included in next release.
J. R. Okajima
-
Hello shawn,
shawn wilson:
> However, I an issue - I don't know how to make rules for which fs gets
> updated. I'm thinking everything needs to overlay at the same point,
> so directory writes might go to one fs or another - I think the base
> should generally be ro, but the automation config and
o bugfix
- tmpfs-idr.patch in aufs3-standalone.git
support for the hidden internal tmpfs for SYSV IPC shm.
Reported and tested by Guan Xin and Nikolay Pertsev.
o news
- begin supporting fallocate(2), tested by Jeremy Lin.
- remove CONFIG_AUFS_SP_IATTR and fs/aufs/f_op_sp.c.
This mainline (an
Bhushan, Florian,
Do you still remember the discussion about FS_USERNS_MOUNT in last year?
I am going to introduce a new configuration CONFIG_AUFS_USERNS_MOUNT
which sets FS_USERNS_MOUNT which allows an unprivileged user mount aufs
within userns.
In other words, I cannot decide which way to go a
Florian Klink:
> However, as we're not really sure about any possible security issues
> this could bring to aufs, it would probably the best to let users decide
> by adding a CONFIG_AUFS_USERNS_MOUNT option (attached with a fat warning
> that it's not really tested and could cause security issues)
o news
- a new module parameter "allow_userns"
- new branch attributes for copy-up on open, "coo_reg" and "coo_all"
Unfortunately I have a hardware trouble on my test machine and I could
not test aufs3.x-rcN branch for this release. But the tests for 3.15,
3.14, 3.12.x, and 3.9 were done.
J. R.
o news
- introduce a new branch attribute "moo," which stands for "move-up on
open."
- return of a mount option "dirperm1"
J. R. Okajima
--
- aufs3-linux.git#aufs3.9..aufs3.12.x branch
aufs: copy-up on open, doc
au
Mostly these changes are not significant to users.
J. R. Okajima
- aufs3-linux.git
aufs doc: replace a broken URL
aufs: tiny, minor optimization for br entries under sysfs
aufs: describe more about move-down
aufs: mvdown, return a
Hello James,
James B:
> I've gotten this kernel oops after running the system continuously for about
> 14-15 hours.
> This only happens when the system is under load most of the time (load is
> around 95% of CPU most of the time).
> If the system load is lower (idle being 40-50% load) this doe
James B:
> The filesystem operations are indeed not heavy; I have a few cronjobs that
> performs various sanity checks by doing those mv/ls/cat/touch etc and they
> will run at the same frequency whether the CPU is loaded or not. When the CPU
> is not loaded the kernel can last longer (so far I
Hello Sergey,
Sergey Korshunoff:
> I use aufs (openvz kernel 2.6.32) for mounting root fs for containers (CT).
> And faced a problem with checkpoint/restore. When NFS is used between an
> aufs mount point and CT root, then checkpoint/restore is working fine
> (aufs is compiled with AUFS_EXPORTS=
Sergey Korshunoff:
> I will try to explain the problem. A file from a union have a path
> which don't point inside a union. Insteed a file path is a real path
> to the file inside a branch. Checkpoint/restore can not deal with
> this. I solved a problen by using a user space bind utility (fuse
>
James B:
> My first attempt resulting in a total crash while I was sleeping, so I can't
> see anything.
> I will try again.
Would post the output of diff(1) to confirm the changes you made?
By the way, my weekly test for aufs release takes 6 - 8 hours per a
version and I am maintaining several v
Sergey Korshunoff:
> return a real path for a file located inside union. Example:
> /mnt/union
> /branch_rw
> /branch_ro
> mount -t aufs o dirs=/branch_rw=rw,/branch_ro=ro none /mnt/union
> For the file README.txt in /branch_ro opened by program from
> /mnt/union/README.txt a path returned by a ke
James B:
> > Would post the output of diff(1) to confirm the changes you made?
>
> Attached.
Thanks. The diff looks good, but I found an issue.
Please add a condition to the code we added such like this.
if (d) {
au_debug_on();
AuDbgDentry(d);
Sergey Korshunoff:
> a kernel part of the openvz checkpoint/restore preform a checks about
> a path of the opened files. Then it tells:
Then how does the "openvz checkpoint/restore" get the opened file?
Note that I am not a user of openvz checkpoint/restore, and know nothing
about it. Still I do
Sergey Korshunoff:
> This is the kernel part of the checkpoint/restore which saves/resores
> an application open descriptors. I just checked a openvz 2.6.18 with
> unionfs v1.4 The same problem while a message is differ:
I am totaly confused.
Are you talking about unionfs? If so, you got perfectl
Hello Steve,
"Steve Ziuchkovski":
> Right after I sent the message I figured out the problem. My host machine's
> strip was being run to strip the aufs library, but it was built with a
> cross-compiler. I ended up having to replace /usr/bin/strip on my host with
> a symlink to my toolchain's stri
Hello Ian,
Ian Campbell:
> This include is added by aufs3-mmap.patch but causes circular
> dependencies on arm64 as seen with the Debian kernel packages in
:::
> According to http://article.gmane.org/gmane.linux.ports.arm.kernel/342042
> > The added mm.h->fs.h looks like a mistake, it sho
o bugfix
- missing mnt_want_write in moo
In move-up-on-open, between copying-up to the upper branch and unlinking
on the lower branch, mnt_want_write is necessary.
- restore the lost unlock in an error path
A call to au_unpin() in an error path was lost by an old commit
fb3f6aa
Ian Campbell:
> The following patch which does what I think you are suggesting works OK
> for me too.
Thanks for the patch.
#ifndef CONFIG_MMU was less important since the built kernel doesn't
contain the functions defined in the header as long as they are unused.
But by moving them into a source
James B:
> Update on the issue: I've decided to try another path - Russel King the ARM
> kernel maintainer has updated his cubox-i patches to work with 3.16-rc kernel
> (so now the cubox-i can run mainline kernel + his 40-odd patches). I have
> tried building 3.16-rc5 kernel with his patches (u
Sergey Korshunoff:
> Sorry, I'm back.
> The key of the problem with suspend/resume of the openvz container using
> aufs as a root fs is a file descriptor opened by aufs itself.
For me, the key of the problem is
- less description about the problem and the environment.
- even after I quoted the ne
Ian Campbell:
> > #ifndef CONFIG_MMU was less important since the built kernel doesn't
> > contain the functions defined in the header as long as they are unused.
> > But by moving them into a source file, the built kernel will contain
> > them. So ifndef CONFIG_MMU is necessary this time.
>
> Yes
> Re-reading several makefiles,
> - fs/proc/Makefile builds nommu.o and task_nommu.o unconditionally.
> - mm/Makeilfe builds nommu.o unconditionally.
>
> So I change my mind and stop adding ifndef CONFIG_MMU.
Oops! I was wrong. Sorry.
Please ignore my previous mail.
J. R. Okajima
-
Ian Campbell:
> In file included from /=ABPKGBUILDDIR=BB/include/linux/mm.h:23:0,
> from /=ABPKGBUILDDIR=BB/include/linux/pid_namespace.h:6,
> from /=ABPKGBUILDDIR=BB/include/linux/ptrace.h:9,
> from /=ABPKGBUILDDIR=BB/arch/arm64/include/asm/compa
Hello all,
I am going to stop maintaining aufs3.9 ... aufs3.14 versions, and make
aufs3.15 a new base version. It will happen after aufs3.16 or aufs3.17
is released.
If you have any objections, please let me know.
J. R. Okajima
-
Ian Campbell:
> There were some other errors in the original buildd log at
> http://buildd.debian-ports.org/status/fetch.php?pkg=linux&arch=arm64&ver=3.14.12-1&stamp=1405234443
> but they were resolved as part of this patch too so I didn't investigate
> much further. Some of them were missing pr
Ed W:
> Not objecting, but just noting that 3.14 was named a "long term
> release". Does this affect your thoughts?
Hmm, maybe.
But I will wait to see opinions from more people.
J. R. Okajima
--
Want fast and easy ac
Sergey Korshunoff:
> I'm trying to use a aufs as a root fs for container. I use openvz
> kernels 2.6.18 and 2.6.32. While container starts, stops and works
> well it can not be suspended. There is nothing special to a kernel
> version and even union fs type (aufs, uniionfs). Problem is common to
>
Guan Xin:
> Does it mean the long term 3.{10,12,14} will also be unmaintained?
Yes.
But linux-3.14 is marked as long term, I may change my base version to
3.14 from 3.15.
> If it happens after aufs3.16 is released, then possibly means next week?
Yes, this is the fastest case.
J. R. Okajima
Jakob Blomer:
> we at Cern would be glad if 3.10 support could be continued. Our CernVM
> [1] kernel uses a 3.10 long-term kernel with aufs patches. While we can
> work on moving CernVM to 3.14, more critically is that the RHEL7 kernel
> is largely based on 3.10. RHEL (more specifically the
Jakob Blomer:
> Let me first say that we are very happy with the high quality and the
> performance of aufs and we are very glad for all the work you put into
> maintaining and improving it!
My pleasure.
> The aufs version that matches closest the RHEL6 kernel is aufs2.1-32.
> For the new RH
Hello Pete,
Thank you very much for your contribution.
I've repeatedly asked Sergey how to reproduce and the details, but got
no good answers. I hope your contribution will make the details clearer.
Hans-Peter Jansen:
> In order to perform a proper suspend/resume cycle, the CT has to arrange
>
Hello Sean,
Sean Lynch:
> This is against the aufs3.9 branch. The only change is to remove the use of
> the GNU-specific error_at_line and the associated error.h, replacing it
> with BSD's err(), which works with both glibc and musl.
One difference is err() terminates the application even if err
> Sean Lynch:
> > This is against the aufs3.9 branch. The only change is to remove the use of
> > the GNU-specific error_at_line and the associated error.h, replacing it
> > with BSD's err(), which works with both glibc and musl.
>
> One difference is err() terminates the application even if errno
James B:
> Even with this I still get thousands of entries coming out from the serial
> console (I've already killed klogd and syslogd - if I don't I will get a
> multiple of that, each time klogd tries to open "etc").
> Mainly output h_d_revalidate from "ps" reading from "proc".
> It this norm
James B:
> Okay now I confirm that it is zero. I had to reboot the box as it gave me rcu
> sched stall anyway ... so this time around I will run with the default
> printk, it seems to be giving me some output from "dmesg -w" (I've got
> something like "d-1" or "i-1 aufs do_rename" followed by t
James B:
> I also saw earlier last week you fixed a bug on au_unpin.
> I haven't applied that - you think I should to that too?
Hmm,,,
I think the missing au_unpin is unrelated to this problem. But
unfortunately I am unsure because the root cause of your problem is not
identified yet.
Mostly the
Sean Lynch:
> I figured since the macro was using errno, err never be called with a 0
> status.
You are right.
But I am subject to make mistakes. :-)
Additioanally 'err_' looks too ugly.
Here is a refined patch. Does it work for you?
J. R. Okajima
a.diff.bz2
Description: BZip2 compressed data
James B:
> The system has been up for 15 hours; normally by now it would have given me
> the oops. But it still looks like it is going strong. I'll update you again
> as time goes on, keep fingers crossed ...
tHat Is a gOOd nEWs.
Sorry, I cannot type well with my fingers crossing...
J. R. Oka
James B:
> The system has been up for 15 hours; normally by now it would have given me
> the oops. But it still looks like it is going strong. I'll update you again
> as time goes on, keep fingers crossed ...
Digging into the aufs history, I've found the bug was born in aufs1 (CVS-age)
On 2008
James B:
> The system has now been up for 46 hours and is still going strong.
> I think we can reasonably be sure that this problem has been fixed - that one
> single "else" fixes it :)
Great!
> My only wonder is why it hasn't surfaced until now, well not in x86_64 and
> x86 area anyway.
> I'
Sean Lynch:
> Now program_invocation_name is missing:
Thank you for testing.
But which version is your musl library?
I confirmed that musl libc has program_invocation_name when I was
writing the patch. Now I read the history and found it was added more
than a year ago (musl v0.9.10.)
b4ea638 201
201 - 300 of 2717 matches
Mail list logo
