sh,all_squash,anonuid=1000,anongid=1000
192.168.0.0/24(rw)
There are other similar mounts present as well and they're all
affected.
Thank you.
All the best,
Dmitry Smirnov
GPG key : 4096R/53968D1B
---
Platitude: an idea (a) that is admitted to be true by everyone, and (b)
that is not tru
ading
"nfs-kernel-server" and corresponding "nfs-common".
Please advise. Thanks.
Cheers,
Dmitry Smirnov
GPG key : 4096R/53968D1B
--- System information. ---
Architecture: amd64
Kernel: Linux 3.8-2-amd64
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.deb
I couldn't reproduce on latest Squeeze (linux/2.6.32-5) so perhaps it is a
regression...
Regards,
Dmitry.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201303090
I found that dropping dentries and inode caches with
sudo su -c 'echo 2 > /proc/sys/vm/drop_caches'
is helpful to avoid performance degradation if given before each tree walk
probably because it drops nfs_inode_cache.
However I don't understand why dropping pagecache by
sudo su
walk the same tree again.
Setting "acregmin=0" makes directory walk time >24 seconds even for the first
walk.
Cheers,
Dmitry Smirnov
GPG key : 4096R/53968D1B
--- System information. ---
Architecture: amd64
Kernel: Linux 3.7-trunk-amd64
--- Package info
It has been done, thanks for noticing. :)
Dmitry.
On Fri, 20 Jan 2012 01:11:08 Aron Xu wrote:
> Please update Format-Specification url in debian/copyright, then your
> package is in good shape to upload, :)
signature.asc
Description: This is a digitally signed message part.
Hi Aron,
Thank you for fantastic review.
I addressed all the issues in the updated package available from
http://mentors.debian.net/debian/pool/main/t/tupi/tupi_0.1+git12-1.dsc
[data is separated into tupi-data package; dpkg-shlibdeps has been given path
to plugins]
Please ignore minor linti
Sorry Ben,
I feel like I need to clarify some ambiguity of our communication.
When in reply to bug filed against linux-image-amd64 you sad "Your request
cannot be satisfied since the MEMTEST option is only available for x86",
my perception let me think that for some reason you meant the feature
On Monday 05 December 2011 16:53:22 Ben Hutchings wrote:
> Your request cannot be satisfied since the MEMTEST option is only
> available for x86. However, I suspect that's all you really care about.
So the feature won't be available on amd64?
Just x86 is a bit disappointing but certainly better
On Friday 02 December 2011 07:59:02 Jonathan Nieder wrote:
> > Having said that I don't know if it's sensible to add to Debian as I
> > didn't test runtime and binary size overhead.
Binary size overhead is really negligible.
> No opinion on that from me. It does seem a shame that many kinds of
>
On Thursday 01 December 2011 23:09:03 Jonathan Nieder wrote:
> (Kernel image size is also a consideration, though probably not a
> major worry in this particular example.)
Indeed. In this case we're talking about 130 lines of source code (3 KB), see
arch/x86/mm/memtest.c
> > If just few requests
I would like to reopen this discussion since there are some unanswered
questions.
Are we censoring certain Linux Kernel features because "they are not good
enough"?
If so,
* How do we decide what experimental feature is OK?
(For example we have btrfs along with many other things,
Dear intrigeri,
>This wishlist bug is a duplicate of #556365, which was closed (for
>very good reasons, if you ask me). Therefore, I believe it should be
>closed as well.
I very much disagree, unless this wishlist will be closed by enabling the
feature requested.
This *useful* feature has been r
Package: linux-image-amd64
Severity: wishlist
It would be very nice to have 'memtest' option enabled by default in all Debian
kernels.
This tiny feature is only activated with boot-time parameter so it is harmless,
but powerful for those who want to use it.
As described in http://onlyjob.blogspot.
14 matches
Mail list logo
