Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool
Here's the latest version of the patches:
http://people.freebsd.org/~avg/zfsboot.patches.4.diff
John,
the first of the patches implements the approach that we previously discussed.
All arguments are passed starting at a fixed offset that should provide enough
space for extending argument list. The first of the extended arguments should
be
a size of the arguments (including the size field). Then it's easy to write
something like:
struct xargs
{
uint32_t size;
...
};
...
struct xargs xargs;
xargs.size = sizeof(xargs);
...
__exec(..., xargs);
Marius, Gavin,
patch 1f94d9a is my attempt of adapting your sparc64 ZFS code to my larger
changes
in patch ae5a9c6. I have the patches separate to facilitate the review. They
should be committed together. I have only compile-tested the sparc64/ofw part,
so
it could have some grave bugs or omissions.
Could you please review and/or test this patch?
I will greatly appreciate any discussion, suggestions, help.
I again invite everyone else to take part in the review and testing.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool
on 03/05/2012 18:02 Andriy Gapon said the following:
>
> Here's the latest version of the patches:
> http://people.freebsd.org/~avg/zfsboot.patches.4.diff
I've found a couple of problems in the previous version, so here's another one:
http://people.freebsd.org/~avg/zfsboot.patches.5.diff
The important change is in the first patch (__exec args).
> John,
> the first of the patches implements the approach that we previously discussed.
> All arguments are passed starting at a fixed offset that should provide enough
> space for extending argument list. The first of the extended arguments
> should be
> a size of the arguments (including the size field). Then it's easy to write
> something like:
> struct xargs
> {
> uint32_t size;
> ...
> };
> ...
> struct xargs xargs;
> xargs.size = sizeof(xargs);
> ...
> __exec(..., xargs);
>
>
> Marius, Gavin,
> patch 1f94d9a is my attempt of adapting your sparc64 ZFS code to my larger
> changes
> in patch ae5a9c6. I have the patches separate to facilitate the review. They
> should be committed together. I have only compile-tested the sparc64/ofw
> part, so
> it could have some grave bugs or omissions.
> Could you please review and/or test this patch?
> I will greatly appreciate any discussion, suggestions, help.
>
> I again invite everyone else to take part in the review and testing.
>
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: The user-mode stack space is how many bytes?
I have some questions.As follows ，The kernel address space is how much? How it is distributed？ Where can I see?I can adjust it's bigger?What should I do if I can？The change will make some applications can not run? Sorry, my English is poor. I'm looking forward to your reply. Thank you. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
UFS+QUOTA+GIANT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I recently was re-evaluating my needs for a custom kernel vs GENERIC. One of these was due to QUOTA support, which apparently is not in GENERIC due to the GIANT lock [1]. I see that a patch was written for 7-current/8 [2], but never merged in. Are there plans to resume this work? Regards, Bryan Drewery [1] (rwatson) http://lists.freebsd.org/pipermail/freebsd-stable/2005-November/019458.html [2] http://people.freebsd.org/~kib/quotagiant/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPotXrAAoJEG54KsA8mwz50fIP/jocw6jvojh0fhyfMG+1jTe2 JRcllPybQ3HhBKrCsfrhr0T8Ph/c5bMkjWTVl8A71Cq7wZmtHfwzKb7QSweEN29O yerLQKz39IJE5pCGdJqiQSWzfmyjSOtE3xv2PZdZuBCzAnV+dHK5hd4D5VCAjJor 1ZXWOixXjhBxXz5PpD/3w1YQJm9J3RcqmC151bFG3ujzZGwaT2jzQvI9xOEU3jWs /UgSavFUcBhGX30SEjrSsAMNN0nr5Nu9U6+h/hcPkxcIKFt7Zz9D145MWREgkeGs 6rrUSO+TqYeSTEIvHmgv0UNf4/nEGLWnoXd9jvTAu14mZn4tUDRz+wxqz7kQ2lnl sNlcC4BoZsKrzyjtcbE1uE5N25zEVD+sUk6EOukY9lY012TLGJZ0wD5tJWLueBjK 5EFIT3qdMrfcS8YBvnpt8On8+uSfJuroS4hJ/ic4HrajEhTUUTsW2WTPdAFjTEx5 cA+igPYMBRBFl0eZOHZAn2chJfUrmGJmKzuub5avkqFVe2kjbDY9x95XaOkaQTWw UlTC/oOVAHszVU7syFXCPuqQ6hdMCJACTVMUSGyNfMBiXn40orFgfxHijCuHvAr3 Vk1wdY/v0yvMZa8Vd/2hIn7QkHf8IUFYZF0zAcagfiEoCBsPlOUPd0QqJPbCTcBy jecyeS1GDnNx/81PKU4i =vgiH -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: CPU usage so high, fread() on the FILE wrapped by libfetch's fetchXGetURL()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/22/2012 06:54 AM, Yanhui Shen wrote: > Hi, > > I found the CPU usage is pretty high while running 'pkg update', > 'pkg install [fooapp]'. Seems it was caused by fread() on the FILE > wrapped by libfetch's fetchXGetURL() , maybe fetch_read() in > common.c. > > Here is a simple test code: http://pastebin.com/2sP1f4Wv I want to > know whether it is a bug, or misuse of libfetch API, or any other > matter? > > Run and look about its CPU usage (HTTP url has this issue, FTP url > has not): % ./a.out > http://mirrors.163.com/FreeBSD/ISO-IMAGES-amd64/8.3/FreeBSD-8.3-RELEASE-amd64-bootonly.iso > > Env: % uname -a FreeBSD ThinkPad 9.0-STABLE FreeBSD 9.0-STABLE #1: > Tue Apr 10 12:46:50 CST 2012 > shen@ThinkPad:/usr/obj/usr/src/sys/ThinkPad amd64 > Turns out that setting fetchTimeout > 0 fixes this problem. It's been set to 30 in pkgng now. Regards, Bryan Drewery -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPotbaAAoJEG54KsA8mwz5WxUP/iSMjLAShaF/t9+WYtj10FPK 7WWnFj1iquJYN+g0JCDtFnzpqB/VvEfY9sTLqKp/TxCBePS1qPHExzXw9vbFMBDK Em2LCZrlva5vNX7U0vx77dFUJXAEW8zLs6XFeDsmlUBK9CYDK7mDoxNKcLq3LV9w QWOhiTpTe2RprRMqz9FOhQmZ2dB9t5oSuG8BgcEWTfnGS8ANPM45wGH7Vhimai1z 8OCw0T8ZAI7KqDyvxZigACIRWIRb02vBuzVAG1g6EgoVlYQQOwAtH7aCrXaauzlX uWHTjJZYdAl2Lrl60q7qYfyjwFgyVnQIJCEijmT/ydvOMT4huTQrHXvMUiez9qPU wri+6UefQY61C+TVtLMROWlBuCuH4japwxyIlf8QdLbruehcnHjTpFyHDzJMmAj5 V2YU+EfgjOVhoSKyOIQC5VBqK27FlaFMuisD4xisdpJDCJ9k8/LsAjH/PsQwdvei a6CEn3SpMAzrhF3ukv57xIwxSDXdsyoU2VhED5rmrtqzrEFvFjMlflg9MWWHx2m1 KUgmj0ls+WugJrFw/E7PzRU8Qd0xCQRvplDYde16Kzkz+hpXpV6LBYQfWG+YnrRx 5kiJhvNrr7Dstv7Q8u9jNu17KZGSI5p5+FX5oereKymlFxl42rKwyguLXAfHDCXP 1R/HHmtqFSNjSgICw4uC =qd8F -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
I have a few problems related to the distribution of information about memory
I have some questions.As follows ，The kernel address space is how much? How it is distributed？ Where can I see?I can adjust it's bigger?What should I do if I can？The change will make some applications can not run? Sorry, my English is poor. I'm looking forward to your reply. Thank you. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UFS+QUOTA+GIANT
On 3 May 2012 23:01, Bryan Drewery wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > I recently was re-evaluating my needs for a custom kernel vs GENERIC. > One of these was due to QUOTA support, which apparently is not in > GENERIC due to the GIANT lock [1]. This is no longer true since 6.4. it's just that nobody cares to turn them on. -- wbr, pluknet ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
