Greater than 80% volume capacity: OK for large static storage?

[Bidule0hm]

I wonder if there's any solution to defragment a ZFS pool?

 

[jgreco]

I swear, I'm gonna get out a big LART and start going to town on the next smartaleck commenter. ;-)

 

[DifferentStrokes]

I swear, I'm gonna get out a big LART and start going to town on the next smartaleck commenter. ;-)

Then you could fragment their bones to match their pool. :D Wonder what the command is to fix that?

 

[jgreco]

dd if=/dev/zero of=/dev/differentstrokes bs=512

 

[Bidule0hm]

dd if=/dev/jgreco of=/dev/null/ bs=1m :D

 

[DifferentStrokes]

Got to love good ole fashion humor. :)

 

[jgreco]

dd if=/dev/jgreco of=/dev/null/ bs=1m :D

# dd if=/dev/jgreco of=/dev/Bidule0hm bs=512

I need a few copies of myself.

 

[Bidule0hm]

chmod 700 /dev/Biduleohm
rm -f /dev/jgreco

 

[jgreco]

rm -f /dev/Bidule0hm

Wow that's drastic dude. ;-)

 

[Bidule0hm]

Just a bit...

That is drastic: rm -rf /* :D

Edit: Eh, didn't saw you've changed the name, cheater :p

Edit²: fix'd.

 

[jgreco]

Just a bit...

That is drastic: rm -rf /* :D

Edit: Eh, didn't saw you've changed the name, cheater :p

Edit²: fix'd.

# id
uid=0(root) gid=0(wheel) groups=0(wheel)
#

 

[Bidule0hm]

Can't see the image in my CLI...

 

[jgreco]

Can't see the image in my CLI...

Dude, hope you patched those bugs in lynx(1)!

 

[Ericloewe]

So if a single 1GB file is broken into 4KB blocks of which no two are contiguous, but are separated by enough space that it doesn't trip the fragmentation counter, then fragmentation is 0%. Does that make sense to you? Sure doesn't make sense to me. ;)

Well, it wouldn't be divided into 4K blocks if the pool was at 0 fragmentation.

/pedantry

 

[jgreco]

Really? You're a crappy pedant, @Ericloewe ! ;-) ;-)

So, a trivial way to make that happen would be to fill a pool to just shy of ultimate capacity with 4K files, go back, remove a quarter million of them randomly selected, write your 1GB file, then remove all the remaining 4K files.

0% fragmentation but a highly fragmented file. Haven't tried it but "could be fun."

 

[RedBear]

Yeah, atime should usually be off unless you have a good reason to have it on. Pointless write traffic. I've been advocating stuffing it off for about 20 years!

http://marc.info/?l=freebsd-hackers&m=94346965928864&w=2

I am now attempting to figure out the proper way to permanently turn off atime for a given ZFS volume. I notice that this can be done in the GUI for a dataset, but there is no similar "Edit Options" dialog available when the parent volume is selected. Is it the recommended practice to leave the default "atime=on" for the ZFS volume and just disable atime per dataset with the GUI dialog? I can't recall now but was there any way to turn atime off in the GUI during the initial creation of the pool?

I hate to start descending to the command line and changing config files without having a solid understanding of what might interfere with or be ignored by the GUI environment.

 

[Ericloewe]

Really? You're a crappy pedant, @Ericloewe ! ;-) ;-)

So, a trivial way to make that happen would be to fill a pool to just shy of ultimate capacity with 4K files, go back, remove a quarter million of them randomly selected, write your 1GB file, then remove all the remaining 4K files.

0% fragmentation but a highly fragmented file. Haven't tried it but "could be fun."

Obligatory xkcd:

http://xkcd.com/908/

 

[jgreco]

I am now attempting to figure out the proper way to permanently turn off atime for a given ZFS volume. I notice that this can be done in the GUI for a dataset, but there is no similar "Edit Options" dialog available when the parent volume is selected. Is it the recommended practice to leave the default "atime=on" for the ZFS volume and just disable atime per dataset with the GUI dialog? I can't recall now but was there any way to turn atime off in the GUI during the initial creation of the pool?

I hate to start descending to the command line and changing config files without having a solid understanding of what might interfere with or be ignored by the GUI environment.

You're probably best turning it off per-dataset thru the GUI. I don't think there'd be any harm in setting it from the CLI on the parent volume, but the whole use model for inheritance was somewhat different, and doing a one-time change per-dataset thru the GUI isn't onerous.

 

[jgreco]

Obligatory xkcd:

http://xkcd.com/908/

I don't get the relevance. EINSUFFICIENTCOFFEE.

 

[RedBear]

You're probably best turning it off per-dataset thru the GUI. I don't think there'd be any harm in setting it from the CLI on the parent volume, but the whole use model for inheritance was somewhat different, and doing a one-time change per-dataset thru the GUI isn't onerous.

I was going to say "Roger that", but then I ran "mount" after I did something in the GUI and noticed that the whole ZFS volume (and everything inside it) now apparently has noatime set. So I was wrong, you can change it in the GUI for the whole volume. But I am confused as to why the main ZFS volume is listed twice in the GUI as what appears to be a subset of itself, with two vastly different values for Used/Available space. And selecting the top level volume name presents different buttons.