Converting remote server from gmirror to ZFS

Re:

wblock@ said:
However, for performance, I would put filesystems first, and then swap at the (slower) end of the disk.
Click to expand...

Are you sure about this? Many years of standard layouts differs with this view.
 
Pretty sure. Try diskinfo -tv on partitions on the start and end of the disk.

Modern disks put more sectors on the faster-spinning outside edge. So data transfer rates are higher there, slowing towards the inner edge of the disk.

Old drives had the same number of blocks per track, so it didn't matter. That may explain the history of putting swap on the b partition. Or maybe the design assumed heavy use of swap and wanted faster I/O for it.
 
Sorry, I understand the performance issue. The following is arguing both sides of the issue. But why give that to swap? I'm assuming swap is infrequently used. Why not give that area of the disk to the main system instead? Would not the overall benefit be a faster server? If so, why has swap traditionally been near the start of the disk?
 
tuning(7) talks about this a bit. I suspect that the default layout is based on older systems where RAM was much more limited and swapping happened much more frequently.

Most of the operating system is either in RAM (the kernel) or not frequently accessed. So a small system partition to load the kernel and main binaries (/bin, /sbin) for fast booting, then swap for fast swap I/O, then all the rest.
 
Well, I guess it's too late to answer now, but it's good to try out these migration scenarios in a virtual machine (VM). I had to do this on one of my servers without a remote console (Intel s1200bts) and I'm glad I did use a VM before touching the actual hardware. The migration was done without a single glitch (which, I must say, I was really surprised at :-) ).

BTW, what's up with that free space between partitions?
 
matoatlantis said:
Well, I guess it's too late to answer now .. but it's good to try out these migration scenarios in virtual machine (VM). I had to do this on one of my servers without remote console (Intel s1200bts) and I'm glad I did use VM before touching the actual hardware. Migration was done without single glitch (which, I must say, I was really surprised :-) ).
Click to expand...

I like that idea. I'm about to start using some infrastructure management tools. Not sure which yet. That will be one step in doing that.

matoatlantis said:
Btw. what's up with that free space between partitions ?
Click to expand...

That's to ensure 4K alignment.

The space at the end of the disk is in case we add a new HDD, which is slightly smaller, it still 'matches' in size.
 
Out of my curiosity: please can you share the output of the following command? (run under sh):

for i in 1 2 3 ;do diskinfo ada0p$i; done

I'd like to see that alignment. I'm not saying something's wrong, I'm just curious..
 
How's this?

Code: 
[root@:~] # gpart show ada0
=>       34  625142381  ada0  GPT  (298G)
         34        128     1  freebsd-boot  (64k)
        162  616562560     2  freebsd-ufs  (294G)
  616562722    8388608     3  freebsd-swap  (4.0G)
  624951330     191085        - free -  (93M)

[root@:~] # for i in 1 2 3 ;do diskinfo ada0p$i; done
ada0p1	512	65536	128	0	17408	0	16	63
ada0p2	512	315680030720	616562560	0	82944	611669	16	63
ada0p3	512	4294967296	8388608	0	2147501056	8322	16	63
[root@:~] #
 
You must log in or register to reply here.
Back
Top