Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #226401 > unrolled thread

Homebuilt NAS: System Drive Filesystem?

Back to article view | Back to linux.debian.user

Contents

  Homebuilt NAS: System Drive Filesystem? Patrick Bartek <nemommxiv@gmail.com> - 2020-08-22 06:10 +0200
    Re: Homebuilt NAS: System Drive Filesystem? David Christensen <dpchrist@holgerdanske.com> - 2020-08-22 11:00 +0200
      Re: Homebuilt NAS: System Drive Filesystem? Keith Bainbridge <ke1th3216@gmail.com> - 2020-08-23 02:50 +0200
        Re: Homebuilt NAS: System Drive Filesystem? <tomas@tuxteam.de> - 2020-08-23 10:20 +0200
      Re: Homebuilt NAS: System Drive Filesystem? Patrick Bartek <nemommxiv@gmail.com> - 2020-08-23 20:30 +0200
        Re: Homebuilt NAS: System Drive Filesystem? David Christensen <dpchrist@holgerdanske.com> - 2020-08-23 23:30 +0200
          Re: Homebuilt NAS: System Drive Filesystem? Patrick Bartek <nemommxiv@gmail.com> - 2020-08-24 04:40 +0200
          Re: Homebuilt NAS: System Drive Filesystem? Andrei POPESCU <andreimpopescu@gmail.com> - 2020-08-24 10:40 +0200
            Re: Homebuilt NAS: System Drive Filesystem? David Christensen <dpchrist@holgerdanske.com> - 2020-08-24 11:20 +0200
        Re: Homebuilt NAS: System Drive Filesystem? Dan Ritter <dsr@randomstring.org> - 2020-08-24 01:00 +0200
          Re: Homebuilt NAS: System Drive Filesystem? David Christensen <dpchrist@holgerdanske.com> - 2020-08-24 02:50 +0200
    Re: Homebuilt NAS: System Drive Filesystem? Jonathan Dowland <jon+debian-user@dow.land> - 2020-08-24 11:50 +0200
      Re: Homebuilt NAS: System Drive Filesystem? Patrick Bartek <nemommxiv@gmail.com> - 2020-08-24 18:30 +0200
        Re: Homebuilt NAS: System Drive Filesystem? Andrei POPESCU <andreimpopescu@gmail.com> - 2020-08-25 08:40 +0200
          Re: Homebuilt NAS: System Drive Filesystem? Patrick Bartek <nemommxiv@gmail.com> - 2020-08-25 19:10 +0200
      Re: Homebuilt NAS: System Drive Filesystem? David Christensen <dpchrist@holgerdanske.com> - 2020-08-25 02:40 +0200

#226401 — Homebuilt NAS: System Drive Filesystem?

Hi! All:

For my Homebuilt NAS [specs below], I've decided on a very small 32GB
SanDisk flash drive for the system drive to keep the 6 available SATA
II connectors free for storage drives. But I'm concerned about writes
wearing out the flash drive too soon. I don't know if it has wear
leveling built in.  Nothing in the specs about it. So, worse case, I'll
assume it doesn't.

For that reason, I thought EXT4 without journaling would work well.  No
journaling -- issues that causes aside -- would reduce writes a lot.
Then I came across F2FS which I hadn't heard of.  After some reading,
it seems the perfect filesystem for my purposes: It's more "modern" and
faster than EXT4, designed specifically for solid state devices, and
available in the Debian Repo. (I plan to use OpenMediaVault NAS
software which is Debian based.)

Opinions?  Suggestions?  Recommendations?

Thanks


B

THE BOX: ASRock 770DE+ BIOS/MBR Only MB (EFI/GPT Not Supported), AMD
Phenom II X4 CPU at 3.0GHz, 8GB DDR2 RAM (16GB Max), 6 SATA II, 1 IDE
(Master and Slave) -- IDE DVD Writer on Master, 1 Floppy connector, but
no floppy drive, 6 USB 2.0/1.0, 1GB ethernet

[toc] | [next] | [standalone]

#226407

On 2020-08-21 21:02, Patrick Bartek wrote:
> 
> Hi! All:
> 
> For my Homebuilt NAS [specs below], I've decided on a very small 32GB
> SanDisk flash drive for the system drive to keep the 6 available SATA
> II connectors free for storage drives. But I'm concerned about writes
> wearing out the flash drive too soon. I don't know if it has wear
> leveling built in.  Nothing in the specs about it. So, worse case, I'll
> assume it doesn't.
> 
> For that reason, I thought EXT4 without journaling would work well.  No
> journaling -- issues that causes aside -- would reduce writes a lot.
> Then I came across F2FS which I hadn't heard of.  After some reading,
> it seems the perfect filesystem for my purposes: It's more "modern" and
> faster than EXT4, designed specifically for solid state devices, and
> available in the Debian Repo. (I plan to use OpenMediaVault NAS
> software which is Debian based.)
> 
> Opinions?  Suggestions?  Recommendations?
> 
> Thanks
> 
> 
> B
> 
> THE BOX: ASRock 770DE+ BIOS/MBR Only MB (EFI/GPT Not Supported), AMD
> Phenom II X4 CPU at 3.0GHz, 8GB DDR2 RAM (16GB Max), 6 SATA II, 1 IDE
> (Master and Slave) -- IDE DVD Writer on Master, 1 Floppy connector, but
> no floppy drive, 6 USB 2.0/1.0, 1GB ethernet

I ran a Samba server and a backup server on my SOHO LAN using SanDisk 
Ultra Fit 16 GB USB 3.0 flash drives with ext4 for several years.  I 
installed Debian just like I would for a HDD or SSD.  The computers 
worked, and the flash drives did not wear out.  But, they saw light use.


I used a 2015 MacBook Pro 15 with VirtualBox and a Debian desktop as a 
daily driver for about two years.  I used a SanDisk Ultra Fit 128 GB USB 
3.0 flash drive with a macOS filesystem for Time Machine backups.  After 
several months, I was awoken in the middle of the night by the smell of 
burnt electronics -- the flash drive had died.  Now the Mac has a 
SanDisk 128GB High Endurance Video microSDXC Card with an microSD to SD 
adapter.  The SD adapter sticks out further than the Ultra Fit.  I no 
longer use the machine as my daily driver.  The SD card has not failed 
after a year of light use.


If I wanted to use a USB flash drive as a Debian system drive again, I 
would probably just go with an Ultra Fit 16 GB and ext4.  They are 
inexpensive; and if they fail too often, I would try a high endurance SD 
card and USB adapter.


Tuning the system to minimize flash drive writes sounds appealing, but I 
never had much success at it.  Mounting the root filesystem with 
'relatime' or 'noatime' options sounds like a good way to break things, 
and I'm not going to audit an entire Debian system to figure it out.  I 
tried running without swap -- that is a good way to crash your systems. 
I have not tried alternate filesystems, because I want to be able to 
boot a standard Debian Installer and run the rescue console when needed 
(thus precluding ZFS, which I really want).  One trick I have not tried 
is a USB disk on module.  Eventually SSD's became cheap enough that I 
replaced all of the USB flash drives, so I have not pursued this.


David

[toc] | [prev] | [next] | [standalone]

#226434

On 22/8/20 6:49 pm, David Christensen wrote:
> SanDisk 128GB High Endurance Video microSDXC Card


This came up well in a couple of reviews I read yesterday afternoon.

The specific summaries:
After 30+ hours of research and testing, our top choice is the 64GB 
Samsung Pro Endurance. It has the best durability and value of 
endurance-focused cards and carries a 3-year warranty.



For 128GB+ cards on a budget, the Samsung EVO Plus, EVO Select and 
Sandisk Ultra A1 cards are good choices. While cheaper than our 
endurance pick, they lack a warranty and will likely fail earlier.


Sadly the reviews aren't coming up when I search my history in firefox. 
Only the outlets


It's encouraging to see some real world experience.

I'll try to remember to report the details of the system sdcard in my Pi 
next time I have it (the Pi) out of hiding.  It is at least 4years old 
of 24x7 use, mostly dragging files on to back up (usb connected) 
spinning disks.


-- 
Keith Bainbridge

keith.bainbridge.3216@gmx.com
          Please note new address

[toc] | [prev] | [next] | [standalone]

#226439

[Multipart message — attachments visible in raw view] — view raw

On Sun, Aug 23, 2020 at 10:28:53AM +1000, Keith Bainbridge wrote:
> On 22/8/20 6:49 pm, David Christensen wrote:
> >SanDisk 128GB High Endurance Video microSDXC Card
> 
> 
> This came up well in a couple of reviews I read yesterday afternoon.
> 
> The specific summaries:
> After 30+ hours of research and testing, our top choice is [...]
> It has the best durability and value of endurance-focused cards [...]

Wow. Thirty-plus hours. That's endurance ;-P

(sorry, couldn't resist)

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#226446

On Sat, 22 Aug 2020 01:49:45 -0700
David Christensen <dpchrist@holgerdanske.com> wrote:

> On 2020-08-21 21:02, Patrick Bartek wrote:
> > 
> > Hi! All:
> > 
> > For my Homebuilt NAS [specs below], I've decided on a very small 32GB
> > SanDisk flash drive for the system drive to keep the 6 available SATA
> > II connectors free for storage drives. But I'm concerned about writes
> > wearing out the flash drive too soon. I don't know if it has wear
> > leveling built in.  Nothing in the specs about it. So, worse case, I'll
> > assume it doesn't.
> > 
> > For that reason, I thought EXT4 without journaling would work well.  No
> > journaling -- issues that causes aside -- would reduce writes a lot.
> > Then I came across F2FS which I hadn't heard of.  After some reading,
> > it seems the perfect filesystem for my purposes: It's more "modern" and
> > faster than EXT4, designed specifically for solid state devices, and
> > available in the Debian Repo. (I plan to use OpenMediaVault NAS
> > software which is Debian based.)
> > 
> > Opinions?  Suggestions?  Recommendations?
> > 
> > Thanks
> > 
> > 
> > B
> > 
> > THE BOX: ASRock 770DE+ BIOS/MBR Only MB (EFI/GPT Not Supported), AMD
> > Phenom II X4 CPU at 3.0GHz, 8GB DDR2 RAM (16GB Max), 6 SATA II, 1 IDE
> > (Master and Slave) -- IDE DVD Writer on Master, 1 Floppy connector, but
> > no floppy drive, 6 USB 2.0/1.0, 1GB ethernet  
> 
> I ran a Samba server and a backup server on my SOHO LAN using SanDisk 
> Ultra Fit 16 GB USB 3.0 flash drives with ext4 for several years.  I 
> installed Debian just like I would for a HDD or SSD.  The computers 
> worked, and the flash drives did not wear out.  But, they saw light use.

Mine's the Ultra Fit, too, but 32GB. I've done some addtional research,
and it looks like it has wear leveling built in.  Read a SanDisk blurb
that all their solid state devices have it by default.  In any case, the
NAS software I'll be using (OpenMediaVault) has a specific plugin for
solid state to reduce write wear to a minimum.

> 
> I used a 2015 MacBook Pro 15 with VirtualBox and a Debian desktop as a 
> [snip]
> 
> 
> If I wanted to use a USB flash drive as a Debian system drive again, I 
> would probably just go with an Ultra Fit 16 GB and ext4.  They are 
> inexpensive; and if they fail too often, I would try a high endurance SD 
> card and USB adapter.

My plan is after the OS install and configuring to just clone the drive
for a quick reinstall, if or when it's needed.

> 
> Tuning the system to minimize flash drive writes sounds appealing, but I 
> never had much success at it.  Mounting the root filesystem with 
> 'relatime' or 'noatime' options sounds like a good way to break things, 
> and I'm not going to audit an entire Debian system to figure it out.  I 
> tried running without swap -- that is a good way to crash your systems. 
> I have not tried alternate filesystems, because I want to be able to 
> boot a standard Debian Installer and run the rescue console when needed 
> (thus precluding ZFS, which I really want).  One trick I have not tried 
> is a USB disk on module.  Eventually SSD's became cheap enough that I 
> replaced all of the USB flash drives, so I have not pursued this.

I'll use "relatime" instead of "noatime." "Relatime" is said to
create less problems with software that needs dates/times when files,
etc. were last modified, accessed, etc.

My systems rarely use swap, and when they does it's only a few
kilobytes. My main 1-year old under-the-desk box with 16GB RAM has
yet to use any.

I won't be using ZFS because of its propensity for lots of RAM. The old
box I'm using for this project has only 8GB of DDR2, and I don't plan
to expand that. OpenMediaVault, to its credit, is very lightweight and
RAM efficient. Perfect for the home NAS on an old system.

Thanks for your input.

B

[toc] | [prev] | [next] | [standalone]

#226455

On 2020-08-23 11:22, Patrick Bartek wrote:
> On Sat, 22 Aug 2020 01:49:45 -0700
> David Christensen <dpchrist@holgerdanske.com> wrote:
> 
>> On 2020-08-21 21:02, Patrick Bartek wrote:
>>>
>>> Hi! All:
>>>
>>> For my Homebuilt NAS [specs below], I've decided on a very small 32GB
>>> SanDisk flash drive for the system drive to keep the 6 available SATA
>>> II connectors free for storage drives. But I'm concerned about writes
>>> wearing out the flash drive too soon. I don't know if it has wear
>>> leveling built in.  Nothing in the specs about it. So, worse case, I'll
>>> assume it doesn't.
>>>
>>> For that reason, I thought EXT4 without journaling would work well.  No
>>> journaling -- issues that causes aside -- would reduce writes a lot.
>>> Then I came across F2FS which I hadn't heard of.  After some reading,
>>> it seems the perfect filesystem for my purposes: It's more "modern" and
>>> faster than EXT4, designed specifically for solid state devices, and
>>> available in the Debian Repo. (I plan to use OpenMediaVault NAS
>>> software which is Debian based.)
>>>
>>> Opinions?  Suggestions?  Recommendations?
>>>
>>> Thanks
>>>
>>>
>>> B
>>>
>>> THE BOX: ASRock 770DE+ BIOS/MBR Only MB (EFI/GPT Not Supported), AMD
>>> Phenom II X4 CPU at 3.0GHz, 8GB DDR2 RAM (16GB Max), 6 SATA II, 1 IDE
>>> (Master and Slave) -- IDE DVD Writer on Master, 1 Floppy connector, but
>>> no floppy drive, 6 USB 2.0/1.0, 1GB ethernet
>>
>> I ran a Samba server and a backup server on my SOHO LAN using SanDisk
>> Ultra Fit 16 GB USB 3.0 flash drives with ext4 for several years.  I
>> installed Debian just like I would for a HDD or SSD.  The computers
>> worked, and the flash drives did not wear out.  But, they saw light use.
> 
> Mine's the Ultra Fit, too, but 32GB. I've done some addtional research,
> and it looks like it has wear leveling built in. > Read a SanDisk blurb
> that all their solid state devices have it by default. 

AIUI all USB flash drives have wear-leveling -- it is a practical 
requirement.  Otherwise, "hot spots" would wear out patches very quickly.


> In any case, the
> NAS software I'll be using (OpenMediaVault) has a specific plugin for
> solid state to reduce write wear to a minimum.

If they've done the engineering, figured it out, and made it a plug-in, 
that sounds ideal.  If you find an explanation of how they do it, please 
post a link.


>> I used a 2015 MacBook Pro 15 with VirtualBox and a Debian desktop as a
>> [snip]
>>
>>
>> If I wanted to use a USB flash drive as a Debian system drive again, I
>> would probably just go with an Ultra Fit 16 GB and ext4.  They are
>> inexpensive; and if they fail too often, I would try a high endurance SD
>> card and USB adapter.
> 
> My plan is after the OS install and configuring to just clone the drive
> for a quick reinstall, if or when it's needed.

Clones are nice.  Good appliances often include backup and restore features.


>> Tuning the system to minimize flash drive writes sounds appealing, but I
>> never had much success at it.  Mounting the root filesystem with
>> 'relatime' or 'noatime' options sounds like a good way to break things,
>> and I'm not going to audit an entire Debian system to figure it out.  I
>> tried running without swap -- that is a good way to crash your systems.
>> I have not tried alternate filesystems, because I want to be able to
>> boot a standard Debian Installer and run the rescue console when needed
>> (thus precluding ZFS, which I really want).  One trick I have not tried
>> is a USB disk on module.  Eventually SSD's became cheap enough that I
>> replaced all of the USB flash drives, so I have not pursued this.
> 
> I'll use "relatime" instead of "noatime." "Relatime" is said to
> create less problems with software that needs dates/times when files,
> etc. were last modified, accessed, etc.

I only use 'relatime' on data disks.  I would not use it on a root 
filesystem.   /boot might be okay.  (I let the installer set the boot, 
swap, and root entries in fstab and I am loath to touch them.)


> My systems rarely use swap, and when they does it's only a few
> kilobytes. My main 1-year old under-the-desk box with 16GB RAM has
> yet to use any.

Run from RAM is definitely the best situation.


> I won't be using ZFS because of its propensity for lots of RAM. The old
> box I'm using for this project has only 8GB of DDR2, and I don't plan
> to expand that.

Two words: bit rot.


We have been discussing dm-integrity on another thread.  I am still 
trying to figure out if it is production ready and supported/ integrated 
on Debian 10.


> OpenMediaVault, to its credit, is very lightweight and
> RAM efficient. Perfect for the home NAS on an old system.

I have mixed feelings about pre-rolled appliance distributions.  If I 
can fumble my way through the UI and solve my needs without 
understanding what is going on under the hood, okay.  I did this with 
IPCop for years.  (And, it was simple enough that I could mess around 
under the hood.)  But, when I tried to make changes and understand what 
was going on under the hood of FreeNAS, it was a disaster.  I started 
over with FreeBSD RELEASE and rolled my own.


> Thanks for your input.

YW.  :-)


David

[toc] | [prev] | [next] | [standalone]

#226460

On Sun, 23 Aug 2020 14:26:15 -0700
David Christensen <dpchrist@holgerdanske.com> wrote:

> On 2020-08-23 11:22, Patrick Bartek wrote:
> > On Sat, 22 Aug 2020 01:49:45 -0700
> > David Christensen <dpchrist@holgerdanske.com> wrote:
> >   
> >> On 2020-08-21 21:02, Patrick Bartek wrote:  
> >>>
> >>> Hi! All:
> >>>
> > [snip]
> >
> > Mine's the Ultra Fit, too, but 32GB. I've done some addtional research,
> > and it looks like it has wear leveling built in. > Read a SanDisk blurb
> > that all their solid state devices have it by default.   
> 
> AIUI all USB flash drives have wear-leveling -- it is a practical 
> requirement.  Otherwise, "hot spots" would wear out patches very quickly.

Wasn't always that way. Even now I wouldn't expect it on cheap "Made in
China" ones which would get lost long before they wear out. :)

> 
> > In any case, the
> > NAS software I'll be using (OpenMediaVault) has a specific plugin for
> > solid state to reduce write wear to a minimum.  
> 
> If they've done the engineering, figured it out, and made it a plug-in, 
> that sounds ideal.  If you find an explanation of how they do it, please 
> post a link.

I've checked the docs and nothing on what that particular plugin
actually does.  OMV just recommends installing it when using flash
or ssds. Once I installed, I'll look around to see if I can find out
what it's doing.

> 
> >> I used a 2015 MacBook Pro 15 with VirtualBox and a Debian desktop as a
> >> [snip]
> >>
> >>
> >> If I wanted to use a USB flash drive as a Debian system drive again, I
> >> would probably just go with an Ultra Fit 16 GB and ext4.  They are
> >> inexpensive; and if they fail too often, I would try a high endurance SD
> >> card and USB adapter.  
> > 
> > My plan is after the OS install and configuring to just clone the drive
> > for a quick reinstall, if or when it's needed.  
> 
> Clones are nice.  Good appliances often include backup and restore features.

Haven't gotten that far into the docs which are poor to say the least.

> 
> >> Tuning the system to minimize flash drive writes sounds appealing, but I
> >> never had much success at it.  Mounting the root filesystem with
> >> 'relatime' or 'noatime' options sounds like a good way to break things,
> >> and I'm not going to audit an entire Debian system to figure it out.  I
> >> tried running without swap -- that is a good way to crash your systems.
> >> I have not tried alternate filesystems, because I want to be able to
> >> boot a standard Debian Installer and run the rescue console when needed
> >> (thus precluding ZFS, which I really want).  One trick I have not tried
> >> is a USB disk on module.  Eventually SSD's became cheap enough that I
> >> replaced all of the USB flash drives, so I have not pursued this.  
> > 
> > I'll use "relatime" instead of "noatime." "Relatime" is said to
> > create less problems with software that needs dates/times when files,
> > etc. were last modified, accessed, etc.  
> 
> I only use 'relatime' on data disks.  I would not use it on a root 
> filesystem.   /boot might be okay.  (I let the installer set the boot, 
> swap, and root entries in fstab and I am loath to touch them.)

We'll see if "relatime" proves bad for / since, except for swap, it will
be the only partition on the system drive.  This old box doesn't support
UEFI/GPT.

> 
> > My systems rarely use swap, and when they does it's only a few
> > kilobytes. My main 1-year old under-the-desk box with 16GB RAM has
> > yet to use any.  
> 
> Run from RAM is definitely the best situation.
> 
> [snip]
> 
> 
> > OpenMediaVault, to its credit, is very lightweight and
> > RAM efficient. Perfect for the home NAS on an old system.  
> 
> I have mixed feelings about pre-rolled appliance distributions.  If I 
> can fumble my way through the UI and solve my needs without 
> understanding what is going on under the hood, okay.  I did this with 
> IPCop for years.  (And, it was simple enough that I could mess around 
> under the hood.)  But, when I tried to make changes and understand what 
> was going on under the hood of FreeNAS, it was a disaster.  I started 
> over with FreeBSD RELEASE and rolled my own.

I initially thought of rolling my own, too, just for the learning
experience, but OMV would save so much time and seems very
configurable.  And it is open source.  Uses Debian as its OS.

B 

[toc] | [prev] | [next] | [standalone]

#226464

[Multipart message — attachments visible in raw view] — view raw

On Du, 23 aug 20, 14:26:15, David Christensen wrote:
> On 2020-08-23 11:22, Patrick Bartek wrote:
> > 
> > I'll use "relatime" instead of "noatime." "Relatime" is said to
> > create less problems with software that needs dates/times when files,
> > etc. were last modified, accessed, etc.
> 
> I only use 'relatime' on data disks.  I would not use it on a root
> filesystem.   /boot might be okay.  (I let the installer set the boot, swap,
> and root entries in fstab and I am loath to touch them.)

Just in case you're not aware of it, 'relatime' is the default since 
Linux 2.6.30, see mount(8).

Just as a data point, I have been running all my disks with 'noatime', 
as far as I recall since before the default was changed and didn't 
notice any strange behaviour.

It might have been a motivation to stop using mboxes with mutt though 
(I'm using only Maildirs for any local storage), which is the often 
quoted example of applications that might break with noatime.

As far as I know also Debian's popularity-contest relies on access 
times, though it probably works fine with 'relatime'.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#226466

On 8/24/20 1:33 AM, Andrei POPESCU wrote:
> On Du, 23 aug 20, 14:26:15, David Christensen wrote:

>> I only use 'relatime' on data disks.  I would not use it on a root
>> filesystem.   /boot might be okay.  (I let the installer set the boot, swap,
>> and root entries in fstab and I am loath to touch them.)
> 
> Just in case you're not aware of it, 'relatime' is the default since
> Linux 2.6.30, see mount(8).
> 
> Just as a data point, I have been running all my disks with 'noatime',
> as far as I recall since before the default was changed and didn't
> notice any strange behaviour.
> 
> It might have been a motivation to stop using mboxes with mutt though
> (I'm using only Maildirs for any local storage), which is the often
> quoted example of applications that might break with noatime.
> 
> As far as I know also Debian's popularity-contest relies on access
> times, though it probably works fine with 'relatime'.
> 
> Kind regards,
> Andrei


Here is my daily driver:

2020-08-24 01:59:36 root@tinkywinky ~
# cat /etc/debian_version ; uname -a
9.13
Linux tinkywinky 4.9.0-12-amd64 #1 SMP Debian 4.9.210-1+deb9u1 
(2020-06-07) x86_64 GNU/Lin


RTFM mount(8):

FILESYSTEM-INDEPENDENT MOUNT OPTIONS

        To  check  the  current  setting  see  the  options  in
        /proc/mounts.


Look at /proc/mounts -- /boot is on sda1 and root is on sda3_crypt:

2020-08-24 02:07:38 root@tinkywinky ~
# egrep 'sda[13]' /proc/mounts
/dev/mapper/sda3_crypt / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/sda1 /boot ext4 rw,relatime,data=ordered 0 0


They both use relatime.


Thanks for the information.  :-)


David

[toc] | [prev] | [next] | [standalone]

#226456

Patrick Bartek wrote: 
> On Sat, 22 Aug 2020 01:49:45 -0700
> David Christensen <dpchrist@holgerdanske.com> wrote:
> 
> > On 2020-08-21 21:02, Patrick Bartek wrote:
> 
> I'll use "relatime" instead of "noatime." "Relatime" is said to
> create less problems with software that needs dates/times when files,
> etc. were last modified, accessed, etc.

This is reasonable.

> My systems rarely use swap, and when they does it's only a few
> kilobytes. My main 1-year old under-the-desk box with 16GB RAM has
> yet to use any.

Depends on what you're running. 

> I won't be using ZFS because of its propensity for lots of RAM. The old
> box I'm using for this project has only 8GB of DDR2, and I don't plan
> to expand that. OpenMediaVault, to its credit, is very lightweight and
> RAM efficient. Perfect for the home NAS on an old system.

I must refute this calumny.

ZFS likes RAM and will use it to the extent possible. It can be
ordered to use a specific (maximum) amount. Deduplication
requires lots of RAM, but hardly anybody actually wants ZFS's
deduplication.

On the nearest server to hand, ZFS is currently using about 2GB
of RAM to support 10TB of available disk space.

-dsr-

[toc] | [prev] | [next] | [standalone]

#226457

On 2020-08-23 15:56, Dan Ritter wrote:

> ZFS likes RAM and will use it to the extent possible. It can be
> ordered to use a specific (maximum) amount. Deduplication
> requires lots of RAM, but hardly anybody actually wants ZFS's
> deduplication.

+1


David

[toc] | [prev] | [next] | [standalone]

#226470

On Fri, Aug 21, 2020 at 09:02:05PM -0700, Patrick Bartek wrote:
>Opinions?  Suggestions?  Recommendations?

If I were doing this, I would remount / as read-only after boot, see
what complains, and make adjustments to either stop those processes
writing, or redirect where they write to (such as mounting something
else over /var/log, or disabling logging, or disabling cron jobs for
services I don't really need, etc)

I've never used F2FS, I did read a bit about it when it was first
announced. It's had several decades less battle-hardening than plain
old ext4, so I'd personally be inclined to avoid it.

But I'd also avoid trying to run / on a flash drive. I just use a
logical volume on my NAS storage for the OS. I can't see a reason not
to.

-- 
Please do not CC me, I am subscribed to the list.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#226475

On Mon, 24 Aug 2020 10:40:30 +0100
Jonathan Dowland <jon+debian-user@dow.land> wrote:

> On Fri, Aug 21, 2020 at 09:02:05PM -0700, Patrick Bartek wrote:
> >Opinions?  Suggestions?  Recommendations?  
> 
> If I were doing this, I would remount / as read-only after boot, see
> what complains, and make adjustments to either stop those processes
> writing, or redirect where they write to (such as mounting something
> else over /var/log, or disabling logging, or disabling cron jobs for
> services I don't really need, etc)

Some good suggestions.  Although, I'm not sure which ones would be
practical or even possible.  Have to do a default install to see how
things get set up.

> I've never used F2FS, I did read a bit about it when it was first
> announced. It's had several decades less battle-hardening than plain
> old ext4, so I'd personally be inclined to avoid it.

Since F2FS is not supported directly for an install, one would have to
convert to it after or configure the flash drive with another computer
before the install. I don't know if it is worth the time to do so.
EXT4 without journaling would be easier.

> But I'd also avoid trying to run / on a flash drive. I just use a
> logical volume on my NAS storage for the OS. I can't see a reason not
> to.

Of the three or four dedicated NAS software packages I've looked at,
all require installing the OS, etc. on its own dedicated drive and NOT
on a drive DATA will be stored on.  Although, I'm sure there's a hack to
do otherwise. On this old box I'm using, it does have an IDE port
(Master and Slave), so I could use that instead of a flash drive, but I
don't have any IDE drives anymore.

Thanks for the input.

B

[toc] | [prev] | [next] | [standalone]

#226484

[Multipart message — attachments visible in raw view] — view raw

On Lu, 24 aug 20, 09:26:57, Patrick Bartek wrote:
> 
> Since F2FS is not supported directly for an install, one would have to
> convert to it after or configure the flash drive with another computer
> before the install. I don't know if it is worth the time to do so.
> EXT4 without journaling would be easier.

The journal is written to only if the filesystem is written to as well.  

Without having any other data than my own, admittedly limited, 
experience[1] it doesn't seem worth disabling the journal, it is only 
written when the filesystem is written to as well anyway.

[1] all my current systems are running from SD cards, with the only 
optimisation being to not configure any swap.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#226486

On Tue, 25 Aug 2020 09:37:20 +0300
Andrei POPESCU <andreimpopescu@gmail.com> wrote:

> On Lu, 24 aug 20, 09:26:57, Patrick Bartek wrote:
> > 
> > Since F2FS is not supported directly for an install, one would have to
> > convert to it after or configure the flash drive with another computer
> > before the install. I don't know if it is worth the time to do so.
> > EXT4 without journaling would be easier.  
> 
> The journal is written to only if the filesystem is written to as well.  

Yes, and every time a log is written to, too.  On my main system,
normal usage, journaling on, I'm getting hard drive activity about 2 to
3 times a minute 24/7/365. And currently, I have firewall logging off
which was writing to log every 2 seconds or so.  The two Roku devices I
have, for some reason, were trying to access this computer, but no
others.  Don't know why.

Some have suggested to remount / read-only, but since my plan is not to
have a separate /home partition, that would cause problems. Probably
will cause problems even if I do.

However, the NAS software I plan to use (OpenMediaVault) has a
specific plugin if you're using solid state devices for the system
and/or DATA drives.  Don't know exactly what it does, or whether it's a
binary or an executable script.  Guess I'll have to wait until I get to
the point of installing it to see what it does.  No details are given
in OMV's docs.
 
> Without having any other data than my own, admittedly limited, 
> experience[1] it doesn't seem worth disabling the journal, it is only 
> written when the filesystem is written to as well anyway.

At least the flash drive I'm using has wear leveling.  And I'm going to
leave about 15% of it unpartitioned to be safe. Plus, clone it, so if
it goes down, I just plug in the clone and I'm up and running.

> [1] all my current systems are running from SD cards, with the only 
> optimisation being to not configure any swap.

Thanks for your input.

B

[toc] | [prev] | [next] | [standalone]

#226481

On 2020-08-24 02:40, Jonathan Dowland wrote:
> On Fri, Aug 21, 2020 at 09:02:05PM -0700, Patrick Bartek wrote:
>> Opinions?  Suggestions?  Recommendations?

> But I'd also avoid trying to run / on a flash drive. I just use a
> logical volume on my NAS storage for the OS. I can't see a reason not
> to.

I find it is easier to administer computers when the operating system is 
on one device/RAID and the data is on another device/RAID (or several, 
one for each subgroup of data) -- e.g. "separation of concerns".


David

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web