Re: gjournal: journaled slices vs. journaled partitions
Carl wrote: Volodymyr Kostyrko wrote: I have some setups were gjournal was put on device rather the on partition, i.e.: [umgah] ~ gmirror status NameStatus Components mirror/umgah0 COMPLETE ad0 ad1 [umgah] ~ gjournal status Name Status Components mirror/umgah0.journal N/A mirror/umgah0 [umgah] ~ glabel status Name Status Components ufs/umgah0root N/A mirror/umgah0.journala label/umgah0swap N/A mirror/umgah0.journalb ufs/umgah0usr N/A mirror/umgah0.journald ufs/umgah0var N/A mirror/umgah0.journale Does the above suggest that you've ended up with individual journal providers for each partition anyway? If so, where are they and have you really achieved anything functionally different? Are they at the end of their individually associated partitions or all together somewhere else? Has the ill-advised journaled small partition issue been successfully overcome through what you've done? First, there is only one journal - for /dev/mirror/umgah0 and it is named /dev/mirror/umgah0.journal. Anything else is just a bsdlabel partitions, there are four of 'em. [umgah] ~ mount /dev/ufs/umgah0root on / (ufs, asynchronous, local, noatime, gjournal) devfs on /dev (devfs, local) /dev/md0 on /tmp (ufs, asynchronous, local) /dev/ufs/umgah0var on /var (ufs, asynchronous, local, noatime, gjournal) /dev/ufs/umgah0usr on /usr (ufs, asynchronous, local, noatime, gjournal) devfs on /var/named/dev (devfs, local) And yes, mirror autosynchronization is turned off, gjournal takes care of that too. It's not stated in manual, but gjournal is typically transparent for any type of access, just in case of UFS file system is marked as journaled so any metadata writes can be distinguished from data writes. Without that gjournal does literally nothing. And what does this mean for your swap partition? Just nothing, it's just swap. It can't be journaled. Laszlo Nagy wrote earlier: Another tricky question: why would you journal a SWAP partition? Volodymyr, does your assertion that gjournal does nothing when a file system is not UFS mean that there is no penalty with regard to your swap partition despite the existence of mirror/umgah0.journalb? I haven't seen any perfomance decrease in this configuration. And according to manual and articles about gjournal it should work this way. Any chance you'd like to share your command sequence for constructing your gmirror'd and gjournal'd filesystem, Volodymyr? :-) If we have two disks (ad0, ad1) it should look like this: gmirror label -b load -n umgah0 ad1 We are getting all drive gmirrored without synchronization (we don't need it - journal would take care of any discrepancies) and with load balance (load was fixed not so long ago in stable and should be fine to go with). gjournal label mirror/umgah0 We are creating a journal on top of our gmirror. It eats 1G from the end of the disks and gives us the rest to use. bsdlabel -wB mirror/umgah0.journal We are writing the standard bsdlabel to the disk and making it bootable. After that we will get one partition 'a'. spam Yes, no fdisk. I don't think this old piece of rough junk is ever needed on machine running FreeBSD solely. It just takes space, it requires compatibility to forgotten-and-abandoned standards and gives nothing more. You have your server dual-booting Windows or Linux? This is the only case you need fdisk for. /spam bsdlabel -e mirror/umgah0.journal Now we are splitting our journal to some partitions. I did it this way: # /dev/mirror/umgah0.journal: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 524288 164.2BSD b: 16777216 * swap c: 7793256140unused0 0 # raw part, don't edit d: 33554432 *4.2BSD e: * *4.2BSD After that we can format this filesystems: newfs -J -L umgah0root /dev/mirror/umgah0.journala newfs -J -L umgah0var /dev/mirror/umgah0.journald newfs -J -L umgah0usr /dev/mirror/umgah0.journale And label the swap: glabel label umgah0swap /dev/mirror/umgah0.journalb You can skip all this glabel thing, I just prefer to have slim fstab, as slim as possible. fstab /dev/label/umgah0swap none swap sw 0 0 md /tmp mfs rw,-s1024m,-S,-oasync 0 0 /dev/ufs/umgah0root / ufs rw,async,noatime 0 1 /dev/ufs/umgah0var /var ufs rw,async,noatime 0 2 /dev/ufs/umgah0usr /usr ufs rw,async,noatime 0 2 /fstab There's a lot more here to describe from moving system to newly created partitions to inserting and rebuilding our first disk to gmirror. All this issues are described in handbook or other articles found on the net. -- Sphinx of black quartz judge my vow. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal: journaled slices vs. journaled partitions
Hello, I built a similar setup last weekend on a new home server with two 500GB drives. I didn't want to only put gmirror and have full drives rebuild on power failure/reset on the system. I was told that putting bsdlabels on a gjournal provider wasn't a good idea but I have yet to have an answer about why... I went with this setup anyway and I made some reset tests to see what happens on reboot and everything always went fine. When building this setup I got one big problem. If the root filesystem (/) was on a gjournal provider, an unclean shutdown when data was being written on the disk rendered the system completely unbootable. I got this message: GEOM_MIRROR: Device mirror/gm launched (2/2) GEOM_JOURNAL: Journal 3672855181: mirror/gma contains data. GEOM_JOURNAL: Journal 3672855181: mirror/gma contains journal. GEOM_JOURNAL: Journal 3868799910: mirror/gmd contains data. GEOM_JOURNAL: Journal 3868799910: mirror/gmd contains journal. GEOM_JOURNAL: Journal mirror/gmd consistent. Trying to mount root from ufs:/dev/mirror/gm.journal Manual root filesystem specification: fstype:device Mount device using filesystem fstype eg. ufs:da0s1a ? List valid disk boot devices empty line Abort manual input mountroot ? List of GEOM managed disk devices: mirror/gmd.journal mirror/gmd mirror/gmc mirror/gma mirror/gm ad10s1c ad10s1b ad8s1c ad8s1b ad10s2 ad10s1 ad8s1 ad10 ad8 acd0 As you can see, in the proposed list of disk devices devices to boot on, mirror/gm.journala is absent. As I and Ivan Voras, that I contacted about this problem, found, the GEOM_JOURNAL thread that is supposed to mark the journal consistent takes too much time to do it with the root filesystem's provider and the kernel try to mount a device that doesn't yet exist. A bug report has been opened about this problem. For my final setup I decided to put the root filesystem on a separate mirrorred slice of 1GB. Since this slice isn't often written on, not many rebuilds should occur in case of power failure. And I made my power failure test by hitting the reset button while writing data on this filesystem and the rebuild on 1GB doesn't takes too much time (at most 20-30 seconds). Now I have the question. Why the load algorith wasn't recommended? Is it fixed in 7.0-RELEASE-p5? Here is my complete setup that seems to boot correctly every times I made my reset tests while writing data on each filesystems. The 2GB gjournal provider is directly on the mirror provider for all mirrored filesystems exept the root one and I made my bsd labels on the gjournal provider, instead of creating a journal for every filesystem. [EMAIL PROTECTED] ~]# cat /etc/fstab # DeviceMountpoint FStype Options Dump Pass# /dev/ad10s1bnoneswapsw 0 0 /dev/ad8s1b noneswapsw 0 0 /dev/mirror/root/ ufs rw 1 1 /dev/ufs/usr/usrufs rw,async2 2 /dev/ufs/var/varufs rw,async2 2 /dev/ufs/tmp/tmpufs rw,async2 2 /dev/ufs/home /home ufs rw,async2 2 /dev/ufs/data /mnt/data ufs rw,async2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 [EMAIL PROTECTED] ~]# mount /dev/mirror/root on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/ufs/usr on /usr (ufs, asynchronous, local, gjournal) /dev/ufs/var on /var (ufs, asynchronous, local, gjournal) /dev/ufs/tmp on /tmp (ufs, asynchronous, local, gjournal) /dev/ufs/home on /home (ufs, asynchronous, local, acls, gjournal) /dev/ufs/data on /mnt/data (ufs, asynchronous, local, acls, gjournal) [EMAIL PROTECTED] ~]# glabel status Name Status Components ufs/usr N/A mirror/data.journald ufs/var N/A mirror/data.journale ufs/tmp N/A mirror/data.journalf ufs/home N/A mirror/data.journalg ufs/data N/A mirror/data.journalh [EMAIL PROTECTED] ~]# gjournal list Geom name: gjournal 372943514 ID: 372943514 Providers: 1. Name: mirror/data.journal Mediasize: 495810966528 (462G) Sectorsize: 512 Mode: r5w5e11 Consumers: 1. Name: mirror/data Mediasize: 497958450688 (464G) Sectorsize: 512 Mode: r1w1e1 Jend: 497958450176 Jstart: 495810966528 Role: Data,Journal [EMAIL PROTECTED] ~]# gmirror list Geom name: data State: COMPLETE Components: 2 Balance: split Slice: 4096 Flags: NOFAILSYNC GenID: 0 SyncID: 1 ID: 990032118 Providers: 1. Name: mirror/data Mediasize: 497958450688 (464G) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: ad8s2 Mediasize: 497958451200 (464G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: HARDCODED GenID: 0 SyncID: 1 ID: 235591066 2.
Re: gjournal: journaled slices vs. journaled partitions
2008/11/4 Volodymyr Kostyrko [EMAIL PROTECTED] 2008/11/4 Gabriel Lavoie [EMAIL PROTECTED]: When building this setup I got one big problem. If the root filesystem (/) was on a gjournal provider, an unclean shutdown when data was being written on the disk rendered the system completely unbootable. I got this message: GEOM_MIRROR: Device mirror/gm launched (2/2) GEOM_JOURNAL: Journal 3672855181: mirror/gma contains data. GEOM_JOURNAL: Journal 3672855181: mirror/gma contains journal. GEOM_JOURNAL: Journal 3868799910: mirror/gmd contains data. GEOM_JOURNAL: Journal 3868799910: mirror/gmd contains journal. GEOM_JOURNAL: Journal mirror/gmd consistent. Just one thing - you have two separate journaled partitions, one journal per one partition. Yes, this is the test setup I made with one journal for / and one journal for /usr. Only an unclean journal on / rendered the journal unbootable. An unclean journal on /usr gave me no problem. If I put the journal on the slice level, with the root filesystem over the journal. Resetting the system while writing data on any filesystem causes the problem as the journal is shared to the root filesystem too. Trying to mount root from ufs:/dev/mirror/gm.journal Manual root filesystem specification: fstype:device Mount device using filesystem fstype eg. ufs:da0s1a ? List valid disk boot devices empty line Abort manual input mountroot ? List of GEOM managed disk devices: mirror/gmd.journal mirror/gmd mirror/gmc mirror/gma mirror/gm ad10s1c ad10s1b ad8s1c ad8s1b ad10s2 ad10s1 ad8s1 ad10 ad8 acd0 As you can see, in the proposed list of disk devices devices to boot on, mirror/gm.journala is absent. As I and Ivan Voras, that I contacted about this problem, found, the GEOM_JOURNAL thread that is supposed to mark the journal consistent takes too much time to do it with the root filesystem's provider and the kernel try to mount a device that doesn't yet exist. A bug report has been opened about this problem. For my final setup I decided to put the root filesystem on a separate mirrorred slice of 1GB. Since this slice isn't often written on, not many rebuilds should occur in case of power failure. And I made my power failure test by hitting the reset button while writing data on this filesystem and the rebuild on 1GB doesn't takes too much time (at most 20-30 seconds). Good to hear it, i've fallen for that too, but the machine isn't powercycled at all and runs on guaranteed power. I had the similar problems with described setup on virtual test machine too, yet entering anything at mountroot prompt gave gjournal a chance to keep up and needed partition comes up eventually... I didn't reported that, thought it was a virtual machine issue. Same thing here, I had a backup installation on another slice and when I gave this one on the prompt, as soon as I hit Enter, GEOM_JOURNAL was marking the journal consistent. I'm happy to hear that I'm not the only one that had this problem. As for my setup. I put / on its own 1GB mirrored slice with auto-synchronization and soft-updates and I put the other filesystems (/home /usr /var /tmp) on a second fully mirrored/journalised slice (with the journal at the slice level), with auto-synchronization on power failure turned off and async mount option. As for the bug report, I consider this is an easily reproductible bug and I hope it will be solved soon! :) Now I have the question. Why the load algorith wasn't recommended? Is it fixed in 7.0-RELEASE-p5? Nope... http://www.freebsd.org/cgi/query-pr.cgi?pr=113885 -- Sphinx of black quartz judge my vow. Gabriel -- Gabriel Lavoie [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal: journaled slices vs. journaled partitions
2008/11/4 Gabriel Lavoie [EMAIL PROTECTED]: When building this setup I got one big problem. If the root filesystem (/) was on a gjournal provider, an unclean shutdown when data was being written on the disk rendered the system completely unbootable. I got this message: GEOM_MIRROR: Device mirror/gm launched (2/2) GEOM_JOURNAL: Journal 3672855181: mirror/gma contains data. GEOM_JOURNAL: Journal 3672855181: mirror/gma contains journal. GEOM_JOURNAL: Journal 3868799910: mirror/gmd contains data. GEOM_JOURNAL: Journal 3868799910: mirror/gmd contains journal. GEOM_JOURNAL: Journal mirror/gmd consistent. Just one thing - you have two separate journaled partitions, one journal per one partition. Trying to mount root from ufs:/dev/mirror/gm.journal Manual root filesystem specification: fstype:device Mount device using filesystem fstype eg. ufs:da0s1a ? List valid disk boot devices empty line Abort manual input mountroot ? List of GEOM managed disk devices: mirror/gmd.journal mirror/gmd mirror/gmc mirror/gma mirror/gm ad10s1c ad10s1b ad8s1c ad8s1b ad10s2 ad10s1 ad8s1 ad10 ad8 acd0 As you can see, in the proposed list of disk devices devices to boot on, mirror/gm.journala is absent. As I and Ivan Voras, that I contacted about this problem, found, the GEOM_JOURNAL thread that is supposed to mark the journal consistent takes too much time to do it with the root filesystem's provider and the kernel try to mount a device that doesn't yet exist. A bug report has been opened about this problem. For my final setup I decided to put the root filesystem on a separate mirrorred slice of 1GB. Since this slice isn't often written on, not many rebuilds should occur in case of power failure. And I made my power failure test by hitting the reset button while writing data on this filesystem and the rebuild on 1GB doesn't takes too much time (at most 20-30 seconds). Good to hear it, i've fallen for that too, but the machine isn't powercycled at all and runs on guaranteed power. I had the similar problems with described setup on virtual test machine too, yet entering anything at mountroot prompt gave gjournal a chance to keep up and needed partition comes up eventually... I didn't reported that, thought it was a virtual machine issue. Now I have the question. Why the load algorith wasn't recommended? Is it fixed in 7.0-RELEASE-p5? Nope... http://www.freebsd.org/cgi/query-pr.cgi?pr=113885 -- Sphinx of black quartz judge my vow. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal: journaled slices vs. journaled partitions
Carl wrote: So how do I achieve per-slice journaling instead of per-partition? The docs only says this: gjournal only supports UFS2. It does not specifically say that you cannot have per-slice journaling. However, since you could have other filesystems on your slice, I bet that slice based journaling is not supported. I thought I read somewhere that because gjournal is block based and not really part of the filesystem, that it could easily be extended for any other filesystem. My imagination said that gjournal was probably therefore only temporarily limited to a slice full of UFS partitions. Anyone know for sure? gjournal needs to know what what data is actually metadata. In case of UFS the -J flag given to newfs tells system that using this fs we should mark metadata for gjournal use. Another tricky question: why would you journal a SWAP partition? Well, I don't really want to, but how big does a partition like /var have to be before it's no longer ill-advised to journal it individually? A fair bit of writing can occur in /var and the scenario my server will occupy has me concerned about inglorious shutdowns. What are the actual reasons for why journaling a small partition is considered a bad idea? Journal needs to bee big enough to amass all modifications. By default it's 1G. Just compare this to the size of your /var. -- Sphinx of black quartz judge my vow. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal: journaled slices vs. journaled partitions
Laszlo Nagy wrote: So how do I achieve per-slice journaling instead of per-partition? The docs only says this: gjournal only supports UFS2. It does not specifically say that you cannot have per-slice journaling. However, since you could have other filesystems on your slice, I bet that slice based journaling is not supported. I thought I read somewhere that because gjournal is block based and not really part of the filesystem, that it could easily be extended for any other filesystem. My imagination said that gjournal was probably therefore only temporarily limited to a slice full of UFS partitions. Anyone know for sure? Another tricky question: why would you journal a SWAP partition? Well, I don't really want to, but how big does a partition like /var have to be before it's no longer ill-advised to journal it individually? A fair bit of writing can occur in /var and the scenario my server will occupy has me concerned about inglorious shutdowns. What are the actual reasons for why journaling a small partition is considered a bad idea? Carl / K0802647 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal: journaled slices vs. journaled partitions
Carl wrote: My goal is to build a 2-disk server configured with gmirror and gjournal for maximum reliability. There will never be a second operating system on the system, but I prefer not to freak out any non-FreeBSD repair tools that might be used, so I will use compatibility instead of dangerously dedicated mode. This means I need one slice, but see no reason for more. Inside that one slice will be the usual array of partitions (ie. /, swap, /var, /tmp, /usr, /data). Now, I think gmirror allows me to mirror the entire drive rather than forcing me to do per-slice or even per-partition mirroring. I'm looking for the simplest in-field replacement procedure when one of the drives dies and I imagine a whole drive mirror achieves this. Am I right? gjournal, OTOH, has me really confused. The man page for gjournal(8) specifically does not recommend that small partitions be journaled. I assume that's because the journal provider rivals the partition in size and is therefore overhead heavy. It seems to me, though, that if I can journal the slice as a whole instead of per-partition journaling, that there will essentially then be only one journal provider for the combination of all partitions (ie. slice) and that the aforementioned overhead becomes minor. Having smaller partitions included in journaling seems like a good thing to me. So how do I achieve per-slice journaling instead of per-partition? Every time I read up on someone else's gjournal implementation, it seems to end with adding partition.journal entries to /etc/fstab. Am I trying to achieve the impossible or ill-advised here? I have some setups were gjournal was put on device rather the on partition, i.e.: [umgah] ~ gmirror status NameStatus Components mirror/umgah0 COMPLETE ad0 ad1 [umgah] ~ gjournal status Name Status Components mirror/umgah0.journal N/A mirror/umgah0 [umgah] ~ glabel status Name Status Components ufs/umgah0root N/A mirror/umgah0.journala label/umgah0swap N/A mirror/umgah0.journalb ufs/umgah0usr N/A mirror/umgah0.journald ufs/umgah0var N/A mirror/umgah0.journale [umgah] ~ mount /dev/ufs/umgah0root on / (ufs, asynchronous, local, noatime, gjournal) devfs on /dev (devfs, local) /dev/md0 on /tmp (ufs, asynchronous, local) /dev/ufs/umgah0var on /var (ufs, asynchronous, local, noatime, gjournal) /dev/ufs/umgah0usr on /usr (ufs, asynchronous, local, noatime, gjournal) devfs on /var/named/dev (devfs, local) And yes, mirror autosynchronization is turned off, gjournal takes care of that too. It's not stated in manual, but gjournal is typically transparent for any type of access, just in case of UFS file system is marked as journaled so any metadata writes can be distinguished from data writes. Without that gjournal does literally nothing. -- Sphinx of black quartz judge my vow. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal: journaled slices vs. journaled partitions
Volodymyr Kostyrko wrote: I have some setups were gjournal was put on device rather the on partition, i.e.: [umgah] ~ gmirror status NameStatus Components mirror/umgah0 COMPLETE ad0 ad1 [umgah] ~ gjournal status Name Status Components mirror/umgah0.journal N/A mirror/umgah0 [umgah] ~ glabel status Name Status Components ufs/umgah0root N/A mirror/umgah0.journala label/umgah0swap N/A mirror/umgah0.journalb ufs/umgah0usr N/A mirror/umgah0.journald ufs/umgah0var N/A mirror/umgah0.journale Does the above suggest that you've ended up with individual journal providers for each partition anyway? If so, where are they and have you really achieved anything functionally different? Are they at the end of their individually associated partitions or all together somewhere else? Has the ill-advised journaled small partition issue been successfully overcome through what you've done? [umgah] ~ mount /dev/ufs/umgah0root on / (ufs, asynchronous, local, noatime, gjournal) devfs on /dev (devfs, local) /dev/md0 on /tmp (ufs, asynchronous, local) /dev/ufs/umgah0var on /var (ufs, asynchronous, local, noatime, gjournal) /dev/ufs/umgah0usr on /usr (ufs, asynchronous, local, noatime, gjournal) devfs on /var/named/dev (devfs, local) And yes, mirror autosynchronization is turned off, gjournal takes care of that too. It's not stated in manual, but gjournal is typically transparent for any type of access, just in case of UFS file system is marked as journaled so any metadata writes can be distinguished from data writes. Without that gjournal does literally nothing. And what does this mean for your swap partition? Laszlo Nagy wrote earlier: Another tricky question: why would you journal a SWAP partition? Volodymyr, does your assertion that gjournal does nothing when a file system is not UFS mean that there is no penalty with regard to your swap partition despite the existence of mirror/umgah0.journalb? Any chance you'd like to share your command sequence for constructing your gmirror'd and gjournal'd filesystem, Volodymyr? :-) Carl / K0802647 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
gjournal: journaled slices vs. journaled partitions
My goal is to build a 2-disk server configured with gmirror and gjournal for maximum reliability. There will never be a second operating system on the system, but I prefer not to freak out any non-FreeBSD repair tools that might be used, so I will use compatibility instead of dangerously dedicated mode. This means I need one slice, but see no reason for more. Inside that one slice will be the usual array of partitions (ie. /, swap, /var, /tmp, /usr, /data). Now, I think gmirror allows me to mirror the entire drive rather than forcing me to do per-slice or even per-partition mirroring. I'm looking for the simplest in-field replacement procedure when one of the drives dies and I imagine a whole drive mirror achieves this. Am I right? gjournal, OTOH, has me really confused. The man page for gjournal(8) specifically does not recommend that small partitions be journaled. I assume that's because the journal provider rivals the partition in size and is therefore overhead heavy. It seems to me, though, that if I can journal the slice as a whole instead of per-partition journaling, that there will essentially then be only one journal provider for the combination of all partitions (ie. slice) and that the aforementioned overhead becomes minor. Having smaller partitions included in journaling seems like a good thing to me. So how do I achieve per-slice journaling instead of per-partition? Every time I read up on someone else's gjournal implementation, it seems to end with adding partition.journal entries to /etc/fstab. Am I trying to achieve the impossible or ill-advised here? Carl / K0802647 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal: journaled slices vs. journaled partitions
So how do I achieve per-slice journaling instead of per-partition? The docs only says this: gjournal only supports UFS2. It does not specifically say that you cannot have per-slice journaling. However, since you could have other filesystems on your slice, I bet that slice based journaling is not supported. Consider this: how would you journal an NTFS file system (and then boot windows after an unclean shutdown?) Another tricky question: why would you journal a SWAP partition? Best, Laszlo ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
