Hello,
On Mon, 5 Mar 2012 18:45:05 +0100
Matthias Drochner wrote:
> Yes, "TRIM" is ATA specific. It was just lazyness because it was
> the shortest name, thus less to type.
> Other possible names would be "discard" or "delete".
> (FreeBSD uses the latter.)
Something (kinda) related - do you kno
Am 05.03.12 20:41, schrieb Edgar Fuß:
> After the recent problems[*] we've been having with our (4.0/amd64) file
> server, I'll surely be facing the question why we're not using that other OS
> everybody else does.
You sureley mean an up-to-date version of NetBSD, right? btw, if you
would fold
On Mon, Mar 05, 2012 at 08:41:39PM +0100, Edgar Fuß wrote:
> After the recent problems[*] we've been having with our (4.0/amd64) file
> server, I'll surely be facing the question why we're not using that other OS
> everybody else does.
>
> So I need some data for that upcoming discussion. Who is
> So I need some data for that upcoming discussion. Who is using NetBSD to ope$
Please don't use paragraph-length lines.
> So I need some data for that upcoming discussion. Who is using
> NetBSD to operate a file server on a scale comparable to or larger
> than ours, i.e. ~200 users, ~1TB storag
On Mon, Mar 05, 2012 at 08:41:39PM +0100, Edgar Fu? wrote:
> After the recent problems[*] we've been having with our (4.0/amd64)
> file server, I'll surely be facing the question why we're not using
> that other OS everybody else does.
>
> So I need some data for that upcoming discussion. Who
On Mon, Mar 05, 2012 at 01:12:43PM -0600, David Young wrote:
> On Mon, Mar 05, 2012 at 06:14:04AM +, David Holland wrote:
> > The problem with that scheme is that you rewrite everything to the
> > flash over and over again anytime something changes, which is going to
> > generate vastly more wr
After the recent problems[*] we've been having with our (4.0/amd64) file
server, I'll surely be facing the question why we're not using that other OS
everybody else does.
So I need some data for that upcoming discussion. Who is using NetBSD to
operate a file server on a scale comparable to or l
On Mon, Mar 05, 2012 at 06:14:04AM +, David Holland wrote:
> The problem with that scheme is that you rewrite everything to the
> flash over and over again anytime something changes, which is going to
> generate vastly more write cycles than just using a normal fs.
This scheme doesn't write an
On Mon, Mar 05, 2012 at 07:10:24PM +0100, Matthias Drochner wrote:
> > How does that interact with fsck? (both with and without wapbl)
>
> I didn't try wapbl yet, but since the trim stuff happens within
> ffs_blkfree() which is only called at the end when a transaction
> gets committed (as I
dholland-t...@netbsd.org said:
> How does that interact with fsck? (both with and without wapbl)
I didn't try wapbl yet, but since the trim stuff happens within
ffs_blkfree() which is only called at the end when a transaction
gets committed (as I understand the code), it should just work -
in the
y...@mwd.biglobe.ne.jp said:
> what's the expected behaviour when you read DIOCTRIM'ed blocks?
It depends on the disk. There are 2 bits in indentification data
which tell how it behaves: read zeroes, undefined or undefined-
but-consistent. (The difference between the latter two is whether
one get
sim...@netbsd.org said:
> the use of the name "TRIM" in the UFS layer could be a bit more
> generic. This same VOP could be used for example to handle freeing up
> blocks with a flash device backing a UFS filesystem. Maybe use
> something like DIOCFREEBLOCKS instead of DIOCTRIM?
Yes, "TRIM" is
rm...@netbsd.org said:
> Do you have plans to remove old IPSEC since netbsd-6 was branched now?
I'll try to prepare it. I'll be on travel next week, that's why
I won't commit anything before Mar 19.
> We can still
> use mbuf tags as a generic mechanism to communicate between different
> componen
13 matches
Mail list logo
