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
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
J. R. Okajima:
> Do you mean you prefer the patch for tmpfs than "trunc_xino" option?
I thought it is better because you wrote: "I hope this patch will be more
effective than aufs "trunc_xino" option."
I only tested patched tmpfs, I did not test "trunc_xino" option, so, I will
te
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
Good day,
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.
Best,
Nikolay
On Wed, Apr 30, 2014 at 12:30 PM, <[1]sf...@users.sourcef
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
J. R. Okajima
Â
But I found a problem in the patch. The internal bitmap should be freed
when unmounting tmpfs but I forgot it.
Now I am considering how to treat this patch. To put it into aufs
release, or to ask LKML to put into mainline.
Until when it is decided, I
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
J. R. Okajima:
The patch and "ino" option are for TMPFS instead of aufs.
Specify "ino" when you mount tmpfs.
Thank you!
Well, I have positive feedback. I booted patched system ( with "ino" option
for TMPFS ) yesterday shortly after your last response to me. System worked
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
J. R. Okajima:
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 mounted tmpfs. Without "ino" or
specifying "noino", the behaviour
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
J. R. Okajima:
I might be wrong about "automatically." Sorry about that.
I'd suggest you to try specifying "trunc_xino" after reading aufs manual.
This is official solution.
If you don't care patching against tmpfs, I can write and send one to
improve the inode number
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
> J. R. Okajima:
> Unfortunately I don't understand what you want to say.
> Do you want to say that 325192 - 325188 = 4 blocks are gone? If so, I'd
> suggest you to try more tests and
> - confirm those 4 blocks are never re-used
> - every time you create/delete a file some blocks
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
> J. R. Okajima:
> In other words, are you sure that XINO files eat up your tmpfs,
>Â Â Â or is it a general problem that your filesystem is too small for
>Â Â Â your files?
I have sufficient "disk space" amount to allocate files on this partition.
Partition /home/user has
"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
On 28/04/14 09:31, sf...@users.sourceforge.net wrote:
> 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
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
On 28/04/14 05:17, sf...@users.sourceforge.net wrote:
>
> 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...
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
22 matches
Mail list logo
