Re: Beating a dead horse

On Wed, 25 Nov 2015, Andreas Gustafsson wrote: The don't have sectors as much as flash pages, and the page size varies from device to device. I'm curious about something, probably due to ignorance of the full dynamics of the vfs(9) layer. Why is it that folks don't choose file system block

Re: Beating a dead horse

On Tue, 24 Nov 2015 21:57:50 -0553.75 "William A. Mahaffey III" wrote: > On 11/24/15 19:08, Robert Elz wrote: > > Date:Mon, 23 Nov 2015 11:18:48 -0553.75 > > From:"William A. Mahaffey III" > > Message-ID:

Re: Beating a dead horse

Swift Griggs writes: > I'm curious about something, probably due to ignorance of the full > dynamics of the vfs(9) layer. Why is it that folks don't choose file > system block sizes and partition offsets that are least-common-factors > that they share with the hardware

Re: Beating a dead horse

On Wed, 25 Nov 2015, Greg Troxel wrote: So there are two issues: alignment and filesystem block/frag size, and both have to be ok. Ahh, a key point to be certain. So that's ok, but alignment is messier. It sure seems that way! :-) We're seeing smaller disks with 4K sectors or larger

Re: (unknown)

In article <24245.1448479...@andromeda.noi.kre.to>, Robert Elz wrote: >Date:Wed, 25 Nov 2015 12:25:50 -0600 (CST) >From:"Jeremy C. Reed" >Message-ID: > > | Is this

Re: Beating a dead horse

Date:Wed, 25 Nov 2015 15:59:29 -0600 From:Greg Oster Message-ID: <20151125155929.2a5f2...@mickey.usask.ca> | time dd if=/dev/zero of=/home/testfile bs=64k count=32768 | time dd if=/dev/zero of=/home/testfile bs=10240k count=32768 | | so

Re: Beating a dead horse

On 11/25/15 16:05, Greg Oster wrote: On Thu, 26 Nov 2015 04:41:02 +0700 Robert Elz wrote: Date:Wed, 25 Nov 2015 14:57:02 -0553.75 From:"William A. Mahaffey III" Message-ID: <56561f54.5040...@hiwaay.net> | f:

Re: Beating a dead horse

Date:Wed, 25 Nov 2015 19:08:59 -0553.75 From:"William A. Mahaffey III" Message-ID: <56565a61.7080...@hiwaay.net> | The other command is still running, will write out 320 GB by my count, | is that as intended, or a typo :-) ? If as wanted, I will

[no subject]

At Wed, 25 Nov 2015 10:00:00 + (UTC) I had a cron job run: for tz in America/Los_Angeles America/Chicago America/New_York \ Asia/Tokyo Europe/Berlin ; do TZ=$tz date -d "Wednesday 22:00utc" +"%A %B %d %I:%M %p %z %Z ${tz}" ; done This resulted in: Wednesday November 25 12:00 PM -0800

[no subject]

Date:Wed, 25 Nov 2015 12:25:50 -0600 (CST) From:"Jeremy C. Reed" Message-ID: | Is this expected behavior? Undefined? A bug? parsedate is full of bugs. I have a fix for some of them (not

Re: Beating a dead horse

Date:Wed, 25 Nov 2015 12:29:15 -0500 From:Greg Troxel Message-ID: | And, there are also disks with native 4K sectors, where the interface to | the computer transfers 4K chunks. That avoids the alignment issue,

Re: Beating a dead horse

Date:Wed, 25 Nov 2015 08:10:50 -0553.75 From:"William A. Mahaffey III" Message-ID: <5655c020.5090...@hiwaay.net> In addition to what I said in the previous message ... | H I thought that the RAID5 would write 1 parity byte & 4 data |

Re:

=> At Wed, 25 Nov 2015 10:00:00 + (UTC) I had a cron job run: => => for tz in America/Los_Angeles America/Chicago America/New_York \ => Asia/Tokyo Europe/Berlin ; do => TZ=$tz date -d "Wednesday 22:00utc" +"%A %B %d %I:%M %p %z %Z ${tz}" ; => done => => This resulted in: => => Wednesday

Re: Beating a dead horse

Date:Thu, 26 Nov 2015 01:41:00 +0700 From:Robert Elz Message-ID: <23815.1448476...@andromeda.noi.kre.to> | so I'd just add | | raidctl -a /dev/wd5f raid2 | | in /etc/rc.local Actually, a better way short term, is probably to put

Re: Beating a dead horse

Date:Wed, 25 Nov 2015 14:57:02 -0553.75 From:"William A. Mahaffey III" Message-ID: <56561f54.5040...@hiwaay.net> | f: 1886414256 67110912 RAID # (Cyl. 66578*- | 1938020) OK, 67110912 is a multiple of 2^11 (2048)

Re: Beating a dead horse

Date:Wed, 25 Nov 2015 13:20:14 -0700 (MST) From:Swift Griggs Message-ID: | I wonder if the same is true for LVM? No idea. I thought it should be easy enough to test, so I just

Re: Beating a dead horse

On Thu, 26 Nov 2015 04:41:02 +0700 Robert Elz wrote: > Date:Wed, 25 Nov 2015 14:57:02 -0553.75 > From:"William A. Mahaffey III" > Message-ID: <56561f54.5040...@hiwaay.net> > > > | f: 1886414256 67110912 RAID

Re: Beating a dead horse

On 11/25/15 12:14, Robert Elz wrote: Date:Wed, 25 Nov 2015 10:52:30 -0600 From:Greg Oster Message-ID: <20151125105230.209c5...@mickey.usask.ca> | Just to recap: You have a RAID set that is not 4K aligned with the | underlying disks.

Re: Beating a dead horse

On 11/25/15 14:26, Swift Griggs wrote: On Thu, 26 Nov 2015, Robert Elz wrote: FFS is OK on NetBSD-7 (not sure about LFS or others, never tried them). Raidframe might be (haven't looked) but both cgd and ccd are a mess... I wonder if the same is true for LVM? Since it's relatively new,

Re: Beating a dead horse

On Thu, 26 Nov 2015 01:08:21 +0700 Robert Elz wrote: > Date:Wed, 25 Nov 2015 10:52:30 -0600 > From:Greg Oster > Message-ID: <20151125105230.209c5...@mickey.usask.ca> > > | Just to recap: You have a RAID set that is not 4K

Re: Beating a dead horse

On Wed, 25 Nov 2015, William A. Mahaffey III wrote: While LVM may have been designed by committee, I am pretty sure it was originally an SGI committee, & seems pretty good to me as well. As a guy who still supports ancient Unix platforms every day, I'll tell you that IRIX categorically rocks

Re: Beating a dead horse

On 11/25/15 12:47, Robert Elz wrote: The real reason I wanted to reply to this message is that last line. wd5 is not being used as a spare. I kind of suspected that might be the case. (Parts of it might be used for raid0 or raid1, that's a whole different question and not material here).

Fan control on nForce430 MCP61 chipset

Greetings all, I'm trying to gain control of the cooling fans, CPU and case, for a DIY home NAS. They're running at 100% regardless of load or idle duration. Fans run high speed using Xpenology (Synology distro), FreeBSD LiveCD from Install img, and NetBSD 6.1.5 and 7.0. Fans under control with

Re: Beating a dead horse

On 11/25/15 19:36, Robert Elz wrote: Date:Wed, 25 Nov 2015 19:08:59 -0553.75 From:"William A. Mahaffey III" Message-ID: <56565a61.7080...@hiwaay.net> | The other command is still running, will write out 320 GB by my count, | is that as

Re: Beating a dead horse

Greg Troxel wrote: > > I would go further than that. Alignment is not only an issue with 4K > > sector disks, but also with SSDs, USB sticks, and SD cards, all of > > which are being deployed in sizes smaller than 128 GB even today. > > I didn't realize that. Do these devices have 4K native

Re: Beating a dead horse

On 11/25/15 00:30, Robert Elz wrote: Date:Tue, 24 Nov 2015 21:57:50 -0553.75 From:"William A. Mahaffey III" Message-ID: <56553074.9060...@hiwaay.net> | 4256EE1 # time dd if=/dev/zero of=/home/testfile bs=16k count=32768 | 32768+0 records

Re: Beating a dead horse

Robert Elz writes: > Date:Mon, 23 Nov 2015 11:18:48 -0553.75 > From:"William A. Mahaffey III" > Message-ID: <5653492e.1090...@hiwaay.net> > > Much of what you wanted to know has been answered already I think, but > not

Re: Beating a dead horse

Greg Troxel wrote: > The other thing would be to change the alignment threshold to 128G. > Even that's big enough that 1M not used by default is not important. > And of course people who care can do whatever they want anyway. I would go further than that. Alignment is not only an issue with 4K

Re: Beating a dead horse

Andreas Gustafsson writes: > Greg Troxel wrote: >> The other thing would be to change the alignment threshold to 128G. >> Even that's big enough that 1M not used by default is not important. >> And of course people who care can do whatever they want anyway. > > I would go further