| reply to jdong
Re: Opinions on XFS vs JFSsaid by jdong:mkfs.xfs -l size=128m Can this be run on a live filesystem with data on it? I'm guessing 'no'...
But I presume adding the option logbufs=8 to the fstab and remounting is safe right?
eg
/dev/sda7 /home/virtual xfs noatime,logbufs=8 0 0
My current filesystem stats:
tg3 mail # xfs_info /home/virtual
meta-data=/dev/sda7 isize=256 agcount=16, agsize=6644759 blks
= sectsz=512 attr=0
data = bsize=4096 blocks=106316144, imaxpct=25
= sunit=0 swidth=0 blks, unwritten=1
naming =version 2 bsize=4096
log =internal bsize=4096 blocks=32768, version=1
= sectsz=512 sunit=0 blks
realtime =none extsz=65536 blocks=0, rtextents=0
Thanks!
Dan |
|
 jdongEat A Beaver, Save A Tree.Premium
join:2002-07-09
Rochester, MI
kudos:1 | No, the mkfs command can NOT be run with data on it. However, if you are running something like LVM where it's cheap to create another 128MB partition, you can switch the log to an external device that's the size you desire, without losing data.
logbufs=8 is a safe hack, as is mounting with nobarriers which removes a set of write cache flushes after each metadata operation. (The latter might get you the best performance)
--
UbuntuForums Administrator: try Ubuntu Linux |
|
| Thanks.
The problem with nobarriers is that it means that in the event of power loss etc there will likely be data / fs corruption, right? |
|
|
|
 CabalPremium
join:2007-01-21
Austin, TX
 ·Suddenlink
| The XFS FAQ has a few good items on the barrier/write back cache situation:
»oss.sgi.com/projects/xfs/faq.html
--
Interested in open source engine management for your Subaru? |
|
jdongEat A Beaver, Save A Tree.Premium
join:2002-07-09
Rochester, MI
kudos:1 | reply to danson1
said by danson1:Thanks. The problem with nobarriers is that it means that in the event of power loss etc there will likely be data / fs corruption, right? It's designed to lessen the chances of metadata corruption on disks with writeback cache but no battery-backup mechanism.
Frankly on such disks poweroff scenarios are so unpredictable that even with barriers on it won't take more than 10 of these resets before you're guaranteed to need an xfs_repair 
I turn it off because it has a huge performance impact, and make up for it by making sure on those drives I never get hard resets
--
UbuntuForums Administrator: try Ubuntu Linux |
|
| ahah - brilliant. Good article above too.
quote:
Q. Should barriers be enabled with storage which has a persistent write cache?
Many hardware RAID have a persistent write cache which preserves it across power failure, interface resets, system crashes, etc. Using write barriers in this instance is not warranted and will in fact lower performance. Therefore, it is recommended to turn off the barrier support and mount the filesystem with "nobarrier".
I actually have a battery backuped RAID card so I can disable barriers with no inpact on reliability =) Huzzah!
by the way - look at the above output from my xfs_info command - what is my current logbuffer size? Is it in fact 128MB already (4096 x 32768)?
Dan |
|
