On Tuesday 2011-04-19 15:18, sf...@users.sourceforge.net wrote:
>
>2. Install aufs2-util
> Generally mount(8) shows /etc/mtab which is maintained by
> mount(8). Your output from mount(8) is /etc/mtab actually, and it
> doesn't look maintained correctly.
> For the aufs entry, some helpers in
On Monday 2011-03-21 10:05, sf...@users.sourceforge.net wrote:
>
>Jan Engelhardt:
>> Mar 19 15:36:40 134.76.82.230 [ 202.960778] kernel BUG at
>> /usr/src/packages/BUILD/aufs-2.1~20110214/obj/desktop/fs/aufs/dynop.c:199!
>
>This line verifies the size of struct address
On Tuesday 2011-04-12 14:10, sf...@users.sourceforge.net wrote:
>
>Jan Engelhardt:
>> mount -t aufs -o br:/home=ro:/var=ro none /mnt
>> mount -t aufs -o br:sometmpfs=rw:/mnt/foo=ro none /mnt/foo
>>
>> would seem to be the logical step, though I can't sa
On Tuesday 2011-04-12 09:55, Ed W wrote:
>On 12/04/2011 07:35, sf...@users.sourceforge.net wrote:
>> Hi Ed,
>>
>> Ed W:
>>> - Assume /ro and /rw, where /ro is a base installation, and /rw contains
>>> directories /home/ and /var/
>>> - Desired end result is that /union should become an aufs mount
On Friday 2011-03-25 16:48, Anatoly wrote:
>Why is it logical?
Because the particular disk is full.
>We have 4 GB of free space.
The data returned by `df` or its underlying syscalls is only valid
for the very moment the information was obtained.
Also, other filesystems are not exact either. Co
On Friday 2011-03-25 16:32, Anatoly wrote:
>Hi everyone!
>
>I have a question.
>Suppose we have 4 drives in 2GB.
>And use aufs scheme "create=mfs".
>
>We write 4 files to 1GB.
>Consequently we have 4 drives are used in half.
>But free 4Gb.
>
>What will happen if we write 2GB file?
Well, the most
Current aufs2-util won't compile because there is no definition of some
plink constants.
plink.c: In function ‘au_plink_maint’:
plink.c:220:26: error: ‘AUFS_CTL_PLINK_MAINT’ undeclared (first use in
this function)
plink.c:220:26: note: each undeclared identifier is reported only once
for each
Observed crash on Linux 2.6.37.2 with aufs-20110207/20110214.
(tmpfs,nfs,nfs)
# mount -t aufs -o br:/.branch@2=rw:/.branch@1=rr:/.branch@0=rr: none /root
Mar 19 15:36:40 134.76.82.230 [ 202.927257] aufs
2.1-standalone.tree-37-20110207
Mar 19 15:36:40 134.76.82.230 [ 202.927691] aufs test_add
On Tuesday 2010-07-20 09:01, Lipkowski, Merten wrote:
>
>Unfortunately I've serious problems with the program encfs.
>When I try to delete a encrypted directory with "rm -r" the whole system hangs
>up.
>
>I've also tried a kernel without aufs, and encfs also caused a system crash.
>So aufs can't
On Wednesday 2010-07-07 09:46, Tomas M wrote:
>
>> Writing a report will not harm much for my aufs work. The report will be
>> something like how to use squashfs and aufs (or other module)
>> effectively. I am not sure it will be whether "the current use in SLAX
>> is best" or "there is another be
On Friday 2010-04-16 10:40, sf...@users.sourceforge.net wrote:
>
>Jan Engelhardt:
>> >> >> 13:25 xensrvneu:/ # mount -t aufs none /x -o br:/root=rw
>> >> >> /sbin/mount.aufs:plink.c:223: AUFS_CTL_PLINK_MAINT: Invalid argument
> :::
>> Yes,
On Monday 2010-05-10 02:24, sf...@users.sourceforge.net wrote:
>> Jan Engelhardt:
>> > Git-over-HTTP is known to be suboptimal; could you perhaps make these
>> > repositories available via git:// transport too? Note that Sourceforge,
>> > where aufs is h
On Wednesday 2010-05-05 01:28, Hans-Peter Jansen wrote:
>Dear Junjiro,
>
>I'm using aufs2-standalone for diverse openSUSE diskless setups, but the
>latest release freezes on boot. For some reason related to the diskless
>setup, where I use a project called kiwi, it's much easier to use the
>sta
On Saturday 2010-04-24 01:27, Hans-Peter Jansen wrote:
>
>This is with kernel 2.6.33.2 with aufs2-20100412 and 2.6.34-rc5 with
>aufs2-20100419, default compilation (no option tweaking).
>
>All packages are available here (for openSUSE 11.1):
>http://download.opensuse.org/repositories/home:/frispe
On Saturday 2010-04-24 04:59, sf...@users.sourceforge.net wrote:
>
>"Hans-Peter Jansen":
>> au_xino_create:659:mount[7044]: xino doesn't support /tmp/.aufs.xino(xfs)
>>
>> Hmm, /tmp is xfs
>
>Correct.
>Aufs2 rejects placing XINO files on XFS while aufs1 allowed it.
Why exactly is that?
-
Hi,
currently the repositories are only reachable via HTTP,
http://git.c3sl.ufpr.br/pub/scm/aufs/aufs2-util.git
Git-over-HTTP is known to be suboptimal; could you perhaps make these
repositories available via git:// transport too? Note that Sourceforge,
where aufs is hosted, does offer support
On Friday 2010-04-16 05:18, sf...@users.sourceforge.net wrote:
>
>Jan Engelhardt:
>> >> 13:25 xensrvneu:/ # mount -t aufs none /x -o br:/root=rw
>> >> /sbin/mount.aufs:plink.c:223: AUFS_CTL_PLINK_MAINT: Invalid argument
> :::
>> 2514 execve(&quo
On Thursday 2010-04-15 14:21, sf...@users.sourceforge.net wrote:
>Jan Engelhardt:
>> 13:25 xensrvneu:/ # mount -t aufs none /x -o br:/root=rw
>> /sbin/mount.aufs:plink.c:223: AUFS_CTL_PLINK_MAINT: Invalid argument
>
>Currently I am guessing your mount(8) passed some inc
Hi,
with a current aufs2-standalone/utils on 2.6.33, I observe that auplink
has a little problem with mounts inside a chroot:
13:25 xensrvneu:~ # mount -t aufs none /srv/nfs/x -o br:/srv/nfs/root=rw
13:25 xensrvneu:~ # umount /srv/nfs/x
13:25 xensrvneu:~ # chroot /srv/nfs
13:25 xensrvneu:/ # mo
On Sep 14 2007 14:45, Tomas M wrote:
>> > Do you know are there (or are not there) any difference at performance
>> > between kmalloc and vmalloc?
>
> This guy here tested kmalloc versus vmalloc.
> http://www.uwsg.indiana.edu/hypermail/linux/kernel/0405.1/0559.html
>
> His result: for runtime perf
On Sep 14 2007 21:25, [EMAIL PROTECTED] wrote:
>Jan Engelhardt:
>> So what is the problem of switching to vmalloc?
>
>Do you know are there (or are not there) any difference at performance
>between kmalloc and vmalloc?
There is probably a small penalty imposed since the virtual
On Sep 14 2007 14:15, Tomas M wrote:
>[EMAIL PROTECTED] wrote:
>> Tomas M:
>>> You said that it's not prefered to allocate large memory blocks which
>>> require several pages. Does the paragraph above say that current aufs
>>> does exactly that? (allocate more). Or it does only for MAX_1023?
>>
On Sep 13 2007 18:34, [EMAIL PROTECTED] wrote:
>Tomas M:
>> I noticed CONFIG_AUFS_BRANCH_MAX_32767 is still commented out in
>> local.mk so I didn't use it yet. Do you recommend it shouldn't be used
>> at all?
>
>It is up to linux memory allocation system.
>When you add a branch, aufs re-allocat
On Sep 13 2007 10:02, Tomas M wrote:
>
>I can see in aufs code that the only difference is that if MAX_127 is
>used, aufs_bindex_t is type 'signed char', while in other cases (for
>MAX_511, MAX_1023 and MAX_32767) aufs_bindex_t is type 'short'.
Think array. char foo[127] is smaller than int foo
On Sep 10 2007 13:24, Tomas M wrote:
>
> > UDF is writable. That is, as long as you have a writable media...
>
>So I am not alone who thinks this :) Thank you
I do not think. I know it.
Jan
--
-
This SF.net email
On Sep 10 2007 12:55, Tomas M wrote:
>
>I noticed the rr branch flag in aufs documentaton (eg br:/directory=rr),
>and I noticed it is used by default for iso9660 and udf filesystems.
>
>I'd like to suggest to use it as default for 'squashfs' filesystem as
>well. If it is already implemented, the
On Aug 4 2007 11:56, Russell Harmon wrote:
>Hmm, that's really weird, the only thing that command does is call the
>kernel's Makefile, and when I do that with "make -f local.mk
>KDIR=/usr/src/linux", I get
To note that the aufs I was talking about is dated 20070729, e.g.
cvs up -D 2007-07-29
>W
On Aug 4 2007 11:34, Russell Harmon wrote:
>>
>> Speaking of which, the modules_install target is not right. It should
>> (ideally) be something like
>>
>> make -C ${yourkerneldir} M=$$PWD modules_install;
>>
>>
>> Jan
>> --
>>
>Hmm, I never noticed it because I patch my kernel, bu
On Aug 4 2007 10:44, Russell Harmon wrote:
>Changed some things so that if you do multiple "make patch" without
>the files having been changed, it won't install the files, and so make
>won't have to rebuild aufs.
>
>Also changed the conditionals to if statements. I find it more
>readable, and prev
29 matches
Mail list logo
