Question from eBay Member.
Hello! You have shown an interest in [Art Glass, Crystal, and Amber with Silver (glass, vase, glasses, bowl, plate, platter, china, set, candlesticks, goblets, platter, serving, tumblers) etc.], such as the kind I often have listed on eBay. If you would like to receive notices this week, please let me know by replying to this email. With YES UNBEATABLE PRICES! The best collection of desirable gifts for all occasions (Holidays, Birthdays, Weddings, Anniversaries, Housewarming...) P.S. If you know a friend or co-worker that would like to receive this kind of notices, you are more than welcome to forward this message to them. Thank You. Paul - The Auctioneer. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Restoring superblock backup?
On Sat, 14 Dec 2002, Andreas Klemm wrote: On Fri, Dec 13, 2002 at 02:28:00PM -0800, Nate Lawson wrote: I've successfully repaired a fs with the superblock backup at 32. Now how do I copy that backup to the default superblock location? fsck_ffs does NOT automatically do this. It does. With fsck -b 32 you use the alternate super block to repair the filesystem just in case the superblock in at the usual place is damaged. After that the filesystem is completely repaired ... Of course the previously damages superblock ... After the fs has been repaired, the alternate sb is not copied to the default sb (currently). -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Restoring superblock backup?
Andreas Klemm wrote: On Fri, Dec 13, 2002 at 02:28:00PM -0800, Nate Lawson wrote: I've successfully repaired a fs with the superblock backup at 32. Now how do I copy that backup to the default superblock location? fsck_ffs does NOT automatically do this. It does. With fsck -b 32 you use the alternate super block to repair the filesystem just in case the superblock in at the usual place is damaged. After that the filesystem is completely repaired ... Of course the previously damages superblock ... fsck does the same things only that you choosed the first copy of the superblock, that is always on block 32. The next copy depends on the size and geometry of the filesystem and is not so easy predictable like the 32 which is always present If FS boundaries are right, one can always try newfs -N, then fsck with -b. I tried this once and succeeded using superblock copy being really more distant from FS start. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: setattr() syscall as proposed by phk
On Sat, 14 Dec 2002, Michael Ranner wrote: Hi there! I have implemented the setattr(), lsetattr() and fsetattr() syscalls for 4.7 and 5.0. You can review my code on http://www.ranner.jawa.at/freebsd.php. Comments and suggestions are welcome. I don't mean to be rude but I doubt the utility of this whole plan. dump/restore are done on disk devices which are at least an order of magnitude slower than a syscall boundary crossing. Going from 4 syscalls to 1 can't make a bit of difference in restore(8) performance. So why is this faster? Something is likely slowing namei() down. However, this should be fixed by improving namei() or whichever subsystem is slowing restore down. Adding new syscalls is not the right answer. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Restoring superblock backup?
On Sun, Dec 15, 2002 at 12:41:58AM -0800, Nate Lawson wrote: After the fs has been repaired, the alternate sb is not copied to the default sb (currently). This doesn't sound valid. It would mean, if your suberblock has crashed and you use the alternate, then every subsequent fsck run would fail and need manual operation to use the alternate superblock. -- Andreas Klemm /\/\/\/\/\/\/\/\/\/\/\ http://www.64bits.de Powered by FreeBSD http://www.apsfilter.org/ \ www.FreeBSD.org / http://people.FreeBSD.ORG/~andreas \/\/\/\/\/\/\/\/\/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: setattr() syscall as proposed by phk
In message [EMAIL PROTECTED], Nate Lawson wri tes: On Sat, 14 Dec 2002, Michael Ranner wrote: Hi there! I have implemented the setattr(), lsetattr() and fsetattr() syscalls for 4.7 and 5.0. You can review my code on http://www.ranner.jawa.at/freebsd.php. Comments and suggestions are welcome. I don't mean to be rude but I doubt the utility of this whole plan. dump/restore are done on disk devices which are at least an order of magnitude slower than a syscall boundary crossing. Going from 4 syscalls to 1 can't make a bit of difference in restore(8) performance. You are wrong about restore: restore is done on a mounted filesystem. So why is this faster? Something is likely slowing namei() down. Because 1 syscall and 2 namei calls are faster than 4 syscalls and four namei calls. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Restoring superblock backup?
On Sat, 14 Dec 2002, Yury Tarasievich wrote: On Fri, Dec 13, 2002 at 02:28:00PM -0800, Nate Lawson wrote: I've successfully repaired a fs with the superblock backup at 32. Now how do I copy that backup to the default superblock location? fsck_ffs does NOT automatically do this. If FS boundaries are right, one can always try newfs -N, then fsck with -b. I tried this once and succeeded using superblock copy being really more distant from FS start. I appreciate the help but you're both answering the wrong question. Go re-read my question above again. The current workaround (as given by mckusick@) is: --- It used to be that when you ran with an alternate superblock, the last question asked by fsck is whether you wish to update the standard superblock. Answering yes would do that update for you. As it appears that that feature got dropped, you can do the copy manually using: dd if=disk skip=32 of=disk seek=16 bs=512 count=16 --- -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: setattr() syscall as proposed by phk
Am Samstag, 14. Dezember 2002 16:24 schrieb Michael Ranner: Hi there! I have implemented the setattr(), lsetattr() and fsetattr() syscalls for 4.7 and 5.0. You can review my code on http://www.ranner.jawa.at/freebsd.php. In between I have modfied 5.0 restore to use setattr(). Because of the new UFS2 birth time attribute, I have to call utimes() before setattr(). Struct stat has no member for the file birth time. Any suggestions to improve setattr() in respect of the new UFS2. The systime of 5.0 restore decreases around 9%. from man utimes For filesystems that support file birth (creation) times (such as UFS2) the birth time will be set to the value of the second element if the second element is older than the currently set birth time. To set both a birth time and a modification time, two calls are required; the first to set the birth time and the second to set the (presumably newer) modification time. Ideally a new system call will be added that allows the setting of all three times at once. I'm also willing to implement the proposed new syscall, any suggestions for name and type of arguments (probably an array of struct timespec). The kernel code already supports an array with all three time stamps. Regards, /\/\ichael Ranner [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] -- JAWA Management Software GmbH - http://www.jawa.at/ Liebenauer Hauptstrasse 2oo - A-8041 Graz Tel +43 316 403274 21 - Fax +43 316 403274 10 -- Mariazell Online - http://www.mariazell.at/ -- -BEGIN GEEK CODE BLOCK- GIT/CS/AT dx(-) s+:(++:) a- C++ UBLVS$ P+$ L-(+)$ E--- W+++$ N+(++) o-- K- w--()$ O-(--) M@ V-(--) PS+++ PE(-) Y+ PGP(-) t+ 5+ X+++() R* tv++ b+(++) DI++ D-(--) G- e h--(*) r++ y? --END GEEK CODE BLOCK-- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Time problem...time is running very fast
Hi ! I have a very weird problem. Time is running very fast on my computer (arround 2 minutes per second - every second two minutes have passed. Some time ago I had the same problem with some other computer who had special Packet Radio card in it (which FreeBSD has no support for), but this time nothing special is in computer. I am running FreeBSD 4.4, machine is old Pentium I/ AMD 133, with two network card and graphic card (this graphic card is hercules(old)/vga). Does anybody have an idea where problem could be? Andy ** * Aleksander Rozman - Andy * Fandoms: E2:EA, SAABer, Trekkie, Earthie * * [EMAIL PROTECTED] * Sentinel, BH 90210, True's Trooper, * *[EMAIL PROTECTED] * Heller's Angel, Questie, Legacy, PO5, * * Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender* * ICQ-UIC: 4911125 * * PGP key available *http://www.atechnet.dhs.org/~andy/ * ** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Time problem...time is running very fast
Update to 4.7 - Original Message - From: Aleksander Rozman - Andy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, December 14, 2002 11:14 PM Subject: Time problem...time is running very fast Hi ! I have a very weird problem. Time is running very fast on my computer (arround 2 minutes per second - every second two minutes have passed. Some time ago I had the same problem with some other computer who had special Packet Radio card in it (which FreeBSD has no support for), but this time nothing special is in computer. I am running FreeBSD 4.4, machine is old Pentium I/ AMD 133, with two network card and graphic card (this graphic card is hercules(old)/vga). Does anybody have an idea where problem could be? Andy ** * Aleksander Rozman - Andy * Fandoms: E2:EA, SAABer, Trekkie, Earthie * * [EMAIL PROTECTED] * Sentinel, BH 90210, True's Trooper, * *[EMAIL PROTECTED] * Heller's Angel, Questie, Legacy, PO5, * * Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender* * ICQ-UIC: 4911125 * * PGP key available *http://www.atechnet.dhs.org/~andy/ * ** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Time problem...time is running very fast
In message [EMAIL PROTECTED], Aleksander Rozman - Andy writes: Hi ! I have a very weird problem. Time is running very fast on my computer (arround 2 minutes per second - every second two minutes have passed. Some time ago I had the same problem with some other computer who had special Packet Radio card in it (which FreeBSD has no support for), but this time nothing special is in computer. I am running FreeBSD 4.4, machine is old Pentium I/ AMD 133, with two network card and graphic card (this graphic card is hercules(old)/vga). Does anybody have an idea where problem could be? Can you mail me a dmesg from boot -v and sysctl kern.timcounter output ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Restoring superblock backup?
On Sun, 15 Dec 2002, Andreas Klemm wrote: On Sun, Dec 15, 2002 at 12:41:58AM -0800, Nate Lawson wrote: After the fs has been repaired, the alternate sb is not copied to the default sb (currently). This doesn't sound valid. It would mean, if your suberblock has crashed and you use the alternate, then every subsequent fsck run would fail and need manual operation to use the alternate superblock. This is indeed the current (bad) behavior, hence my original request for a workaround. I'm working on a patch. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: setattr() syscall as proposed by phk
On Sun, 15 Dec 2002 [EMAIL PROTECTED] wrote: Nate Lawson writes: I don't mean to be rude but I doubt the utility of this whole plan. dump/restore are done on disk devices which are at least an order of magnitude slower than a syscall boundary crossing. Going from 4 syscalls to 1 can't make a bit of difference in restore(8) performance. You are wrong about restore: restore is done on a mounted filesystem. Heh, you took that too literally. I meant the IO is coming from a tape, disk, or other physical media device where latencies for a 32-64k xfer are usually on the order of 1-10 ms or more. So why is this faster? Something is likely slowing namei() down. Because 1 syscall and 2 namei calls are faster than 4 syscalls and four namei calls. Which leaves us back at my previous point which is that something is wrong with caching if 4 namei calls (for the SAME name) are so much slower. A great task would be to examine/test namei(), identify why it's not cached correctly, and fix the underlying problem. The syscall boundary crossing is NOT significant here. -Nate One hand for your own code, and one hand for the infrastructure. -- phk To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: setattr() syscall as proposed by phk
In message [EMAIL PROTECTED], Nate Lawson wri tes: Because 1 syscall and 2 namei calls are faster than 4 syscalls and four namei calls. Which leaves us back at my previous point which is that something is wrong with caching if 4 namei calls (for the SAME name) are so much slower. A great task would be to examine/test namei(), identify why it's not cached correctly, and fix the underlying problem. The syscall boundary crossing is NOT significant here. When you restore a N files, it makes a difference if you need to do 4N syscalls and 4N namei's or just 1N syscalls and 2N nameis. Caching makes the difference smaller, but the fact remains that there is a difference. In particular as N climbs into the range of millions. Don't forget that restore uses (and has to!) paths relative to its root directory, each of the nameis can trivially contain a handful of component names. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Ïðîãðàììèðîâàíèå è äèçàéí
Âàì íóæíà ïðîãðàììà, àíàëîãîâ êîòîðîé åùå íå ñóùåñòâóåò â êîìïüþòåðíîì ìèðå? Èëè Âû õîòèòå, ÷òîáû Âàø ñàéò ñòàë Âàøèì äîñòîéíûì ëèöîì? Âàì òðåáóþòñÿ óñëóãè ïðîôåññèîíàëüíûõ ïðîãðàììèñòîâ è äèçàéíåðîâ? Äëÿ ýòîãî íå îáÿçàòåëüíî êóäà-òî èäòè. Âû ìîæåòå çàêàçàòü íóæíîå Âàì ïðîãðàììíîå îáåñïå÷åíèå èëè äèçàéí Âàøåãî ñàéòà, íå âûõîäÿ èç îôèñà. Ìû ðåàëèçóåì Âàøè ïðîåêòû â ñðîê è ïî ðàçóìíûì öåíàì, è ãàðàíòèðóåì êà÷åñòâî ñâîèõ ðàáîò. Ïðîñòî ñâÿæèòåñü ñ íàìè ïî e-mail [EMAIL PROTECTED] Ïîæàëóéñòà ïîëüçóéòåñü äëÿ ñâÿçè òîëüêî óêàçàííûì e-mail àäðåñîì, à íå îáðàòíûì àäðåñîì äàííîãî ñîîáùåíèÿ! Ïðîåêòíàÿ ñòóäèÿ RxMax Software Äàííàÿ ðàññûëêà ïðîèçâåäåíà â ñîîòâåòñòâèè ñ ÷.4 ñò.29 Êîíñòèòóöèè ÐÔ. Âàø ýëåêòðîííûé àäðåñ ïîëó÷åí èç îòêðûòûõ èñòî÷íèêîâ ÈÍÒÅÐÍÅÒ. ÄÀÍÍÀß ÐÀÑÑÛËÊÀ ßÂËßÅÒÑß ÐÀÇÎÂÎÉ (äóáëèðîâàíèå âîçìîæíî òîëüêî â ñèëó òåõíè÷åñêèõ ñáîåâ). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: setattr() syscall as proposed by phk
setattr() and friends do not exist anywhere outside of this proposal.
I don't particularly like the idea of replacing existing functionality
with a new non-standard system call. The speed issue alone is not enough
to justify the change, nor is Kirk's new creation time field (besides
I thought that field was not supposed to be changeable?).
--
In regards to the implementation itself, I really don't like the idea
of passing a stat structure as an argument. If we are going to have
a 'general' setattr() system call it should be extensible. That is,
something like this:
struct fsattr {
int token;
union {
char pad[32];
struct timeval tv;
time_t t;
etc
} fsu;
}
struct fsattr attrs[] = { { SAT_MTIME, mtime}, { SAT_CTIME, ctime } };
setattr(path, attrs, nattrs);
But it should not take a stat structure. We have enough problems with
the stat structure changing as it is, IMHO. If we use an extensible
structure we won't ever have to change the system call.
This also brings up the possibility that we could integrate setattr-like
functions into the MAC layer, which is already extensible, yes?
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:Heh, you took that too literally. I meant the IO is coming from a tape,
:disk, or other physical media device where latencies for a 32-64k xfer are
:usually on the order of 1-10 ms or more.
:
: So why is this faster? Something is likely slowing namei() down.
:
: Because 1 syscall and 2 namei calls are faster than 4 syscalls and
: four namei calls.
:
:Which leaves us back at my previous point which is that something is wrong
:with caching if 4 namei calls (for the SAME name) are so much slower. A
:great task would be to examine/test namei(), identify why it's not cached
:correctly, and fix the underlying problem. The syscall boundary crossing
:is NOT significant here.
:
:-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: setattr() syscall as proposed by phk
In message [EMAIL PROTECTED], Matthew Dillon w
rites:
setattr() and friends do not exist anywhere outside of this proposal.
I don't particularly like the idea of replacing existing functionality
with a new non-standard system call. The speed issue alone is not enough
to justify the change, nor is Kirk's new creation time field (besides
I thought that field was not supposed to be changeable?).
--
In regards to the implementation itself, I really don't like the idea
of passing a stat structure as an argument. If we are going to have
a 'general' setattr() system call it should be extensible. That is,
something like this:
struct fsattr {
int token;
union {
char pad[32];
struct timeval tv;
time_t t;
etc
} fsu;
}
I don't really like the idea of inventing new oddball structures when
we have perfectly good ones already.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: setattr() syscall as proposed by phk
And, I will also add, in regards to using the stat structure for setattr(), that it creates a serious portability problem as well as a serious forward and reverse compatibility problem. Which fields in the stat structure are going to be ignored by the syscall and which are not? You don't know and there is no way to tell. What happens when some of the modifying operations are allowed and some aren't? There is no way to tell, there is no way to return an error indicating where the problem is. How do you tell setattr() not to modify certain fields? There is no way to do it other then to store special values in the stat structure. What happens to forward portability if the stat structure gets something you didn't know existed and you don't want to change the new field? There is no way to deal with it. In short, using the stat structure for something like this is a bad idea. The system call will wind up being one of those things that we constantly break from release to release as new things come up. If this is going to be done, it needs to be done properly, and while the stat structure may give us instant gratification it will only bite us in the ass down the line. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: setattr() syscall as proposed by phk
In message [EMAIL PROTECTED], Matthew Dillon w rites: And, I will also add, in regards to using the stat structure for setattr(), that it creates a serious portability problem as well as a serious forward and reverse compatibility problem. Which fields in the stat structure are going to be ignored by the syscall and which are not? You don't know and there is no way to tell. This email could have been avoided if you had examined the background information and/or the patch. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
