Richard Coleman wrote:
Scott Long wrote:
/me jumps up and down and waves his hands
The problem with journalling at the block layer is that you pretty
much become forced to journal metadata and data, since the block layer
really doesn't know the distinction, and definitely not in a
Scott Long wrote:
An alternate SoC project that would be very useful is block-level
snapshots. I'm not sure if I'll be able to retain the filesystem
snapshot functionality in UFS with journalling enabled, so moving to
doing the snapshots in the block layer would be a good way to make up
for
Scott Long wrote:
Richard Coleman wrote:
Scott Long wrote:
/me jumps up and down and waves his hands
The problem with journalling at the block layer is that you pretty
much become forced to journal metadata and data, since the block
layer really doesn't know the distinction, and
Hello,
Wonder if you can give me a little advise.
I don't have a background in freebsd. I maintained a Unix V5 system years
ago and I have been called in to look at an installation that is ailing.
This system is a 4.4 version that is acting as a web server. It has some
web functionality on it
Hi,
Sydney Hole Owen Huffaker wrote:
Wonder if you can give me a little advise.
But not much more.
I do have a copy of BSD 4.5 and 5.o from a FreeBSD Unleashed book by Michael
Urban and Brian Tieman. I also have the absolute BSD by Michael Lucas.
I would not touch them as they are
Sydney Hole Owen Huffaker wrote:
Hello,
Wonder if you can give me a little advise.
[..snip..]
I am going to try this tomorrow morning and wondered if you might have some
good advise.
I do have a copy of BSD 4.5 and 5.o from a FreeBSD Unleashed book by Michael
Urban and Brian Tieman. I also
Eric Anderson wrote:
Scott Long wrote:
Richard Coleman wrote:
Scott Long wrote:
/me jumps up and down and waves his hands
The problem with journalling at the block layer is that you pretty
much become forced to journal metadata and data, since the block
layer really doesn't know the
Ivan Voras wrote:
Scott Long wrote:
An alternate SoC project that would be very useful is block-level
snapshots. I'm not sure if I'll be able to retain the filesystem
snapshot functionality in UFS with journalling enabled, so moving to
doing the snapshots in the block layer would be a good
Scott Long wrote:
Again, I'm not exactly sure how a generic mechanism can handle the
distinction of data vs. metadata vs. journal data. Also, what you
I don't care about the distinction at this level - all data is treated
equal :)
___
Ivan Voras wrote:
Scott Long wrote:
Again, I'm not exactly sure how a generic mechanism can handle the
distinction of data vs. metadata vs. journal data. Also, what you
I don't care about the distinction at this level - all data is treated
equal.
But for journalling to work, you must
Scott Long wrote:
Again, I'm not exactly sure how a generic mechanism can handle the
distinction of data vs. metadata vs. journal data. Also, what you
Ivan Voras wrote:
I don't care about the distinction at this level - all data is treated
equal.
Scott Long wrote:
But for
Hello,
We have tried to use qemu for debugging of kernel-level code the same way we
used
bochs in past.
The qemu whether with or without kqemu is quite fast for our needs. The gdb
connects
to guest just fine, however breakpoints break things and qemu stops working.
Our guest OS is FreeBSD
On Tue, 2005-06-07 at 16:52, Scott Long wrote:
David Malone wrote:
On Tue, Jun 07, 2005 at 09:40:05PM +0200, Pawel Jakub Dawidek wrote:
+ Does it make sense to do it this way? Is it worth applying for the SoC?
Not sure. Basically this is simlar what softupdate does, I think.
From
Hi hackers,
I have got an HP DL 385 dual opteron system,
with 2 on-board broadcom network cards.
If I use more NICs, I have to have ACPI turned on.
But if the ACPI is turned on, kernel does not boot,
this is an error message:
panic: npx: can't get ports
Does anybody knows a solution for that ?
Stephan Uphoff wrote:
In my opinion the original proposal described a non volatile write cache
using dedicated cache disks.
Yes, I think that best describes what I have in mind. Here's the
proposal that went to Google yesterday:
http://geri.cc.fer.hr/~ivoras/proposal.pdf
where (physically) are you?
It is possible there is someone nearby that can help you..
Sydney Hole Owen Huffaker wrote:
Hello,
Wonder if you can give me a little advise.
[...]
Regards,
Owen
___
freebsd-hackers@freebsd.org mailing
Hmm... I've used qemu a bit to debug the kernel. Even used
it to debug a loadable module. Here is what I did:
# qemu -s img
# cd path to where the kernel was built on the host
# gdb kernel.debug
(gdb) target remote localhost:1234
...
(gdb) l kldload
739 /*
740 * MPSAFE
741 */
742
I am using kqemu and qemu built from May 2 snapshot if that
matters. This was a stock 5.4-RELEASE complied locallly
with
makeoptionsDEBUG=-g
added the kernel config file. The host was also running 5.4
but that should not matter.
Ugh... Should've done a diff with GENERIC
My company built a tool a few years back for creating a bootable cdrom
based on a running host FreeBSD 3/4 system, which promptly got shelved and
forgotten.I recently had to update it for FreeBSD 5 and thought that
perhaps the community at large could make use it before it gets forgotten
again.
If I understand your email correctly, you were able to get all the
files tar'd up from the original system. And you put those tar's on a
second hard drive that you mounted in the dying system, then a day
later, the primary boot drive died. So right now you have a
non-bootable drive formated
20 matches
Mail list logo
