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


Groups > comp.os.linux.misc > #11693 > unrolled thread

External hard drive usage. NTFS or other file system?

Started byEvgenii Sputnik <esputnik7788@gmail.com>
First post2014-07-31 13:35 -0400
Last post2014-07-31 12:43 -0700
Articles 20 on this page of 35 — 15 participants

Back to article view | Back to comp.os.linux.misc


Contents

  External hard drive usage. NTFS or other file system? Evgenii Sputnik <esputnik7788@gmail.com> - 2014-07-31 13:35 -0400
    Re: External hard drive usage. NTFS or other file system? Aragorn <thorongil@telenet.be.invalid> - 2014-07-31 19:44 +0200
      Re: External hard drive usage. NTFS or other file system? Evgenii Sputnik <esputnik7788@gmail.com> - 2014-08-29 07:45 +0700
        Re: External hard drive usage. NTFS or other file system? Aragorn <thorongil@telenet.be.invalid> - 2014-08-29 03:37 +0200
        Re: External hard drive usage. NTFS or other file system? Robert Heller <heller@deepsoft.com> - 2014-08-28 21:09 -0500
          Re: External hard drive usage. NTFS or other file system? David Brown <david.brown@hesbynett.no> - 2014-08-29 21:16 +0200
      Re: External hard drive usage. NTFS or other file system? Mladen Gogala <gogala.mladen@gmail.com> - 2014-08-29 02:46 +0000
        Re: External hard drive usage. NTFS or other file system? Aragorn <thorongil@telenet.be.invalid> - 2014-08-29 05:14 +0200
          Re: External hard drive usage. NTFS or other file system? William Poaster <wp@dev.null> - 2014-08-29 14:45 +0100
            Re: External hard drive usage. NTFS or other file system? Mladen Gogala <gogala.mladen@gmail.com> - 2014-08-29 15:19 +0000
              Re: External hard drive usage. NTFS or other file system? Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2014-08-30 14:42 +0200
                Re: External hard drive usage. NTFS or other file system? Robert Heller <heller@deepsoft.com> - 2014-08-30 09:09 -0500
                  Re: External hard drive usage. NTFS or other file system? Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2014-08-30 17:41 +0200
                    Re: External hard drive usage. NTFS or other file system? Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2014-08-30 15:21 -0700
                  Re: External hard drive usage. NTFS or other file system? Mladen Gogala <gogala.mladen@gmail.com> - 2014-08-31 17:13 +0000
                    Re: External hard drive usage. NTFS or other file system? Robert Heller <heller@deepsoft.com> - 2014-08-31 13:24 -0500
                      Is VirtualBox "lame"? (Was: something else...) gazelle@shell.xmission.com (Kenny McCormack) - 2014-08-31 20:23 +0000
                        Re: Is VirtualBox "lame"? (Was: something else...) Robert Heller <heller@deepsoft.com> - 2014-08-31 15:51 -0500
                          Re: Is VirtualBox "lame"? Rich <rich@example.invalid> - 2014-08-31 23:58 +0000
                            Re: Is VirtualBox "lame"? Robert Heller <heller@deepsoft.com> - 2014-08-31 21:54 -0500
                              Re: Is VirtualBox "lame"? The Natural Philosopher <tnp@invalid.invalid> - 2014-09-01 07:54 +0100
                            Re: Is VirtualBox "lame"? Marc Haber <mh+usenetspam1118@zugschl.us> - 2014-09-01 08:53 +0200
                          Re: Is VirtualBox "lame"? (Was: something else...) The Natural Philosopher <tnp@invalid.invalid> - 2014-09-01 07:47 +0100
                      Re: External hard drive usage. NTFS or other file system? Mladen Gogala <gogala.mladen@gmail.com> - 2014-08-31 21:00 +0000
                    Re: External hard drive usage. NTFS or other file system? Rich <rich@example.invalid> - 2014-08-31 18:50 +0000
                      Re: External hard drive usage. NTFS or other file system? Mladen Gogala <gogala.mladen@gmail.com> - 2014-08-31 21:01 +0000
                        Re: External hard drive usage. NTFS or other file system? Rich <rich@example.invalid> - 2014-09-01 00:06 +0000
                          Re: External hard drive usage. NTFS or other file system? The Natural Philosopher <tnp@invalid.invalid> - 2014-09-01 07:50 +0100
                Re: External hard drive usage. NTFS or other file system? Mladen Gogala <gogala.mladen@gmail.com> - 2014-08-31 03:18 +0000
    Re: External hard drive usage. NTFS or other file system? Robert Heller <heller@deepsoft.com> - 2014-07-31 12:54 -0500
      Re: External hard drive usage. NTFS or other file system? Unknown <dog@gmail.com> - 2014-08-14 12:39 +0000
        Re: External hard drive usage. NTFS or other file system? Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2014-08-14 08:15 -0700
    Re: External hard drive usage. NTFS or other file system? Tim Watts <tw_usenet@dionic.net> - 2014-07-31 19:08 +0100
      Re: External hard drive usage. NTFS or other file system? Robert Heller <heller@deepsoft.com> - 2014-07-31 14:27 -0500
    Re: External hard drive usage. NTFS or other file system? Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2014-07-31 12:43 -0700

Page 1 of 2  [1] 2  Next page →


#11693 — External hard drive usage. NTFS or other file system?

FromEvgenii Sputnik <esputnik7788@gmail.com>
Date2014-07-31 13:35 -0400
SubjectExternal hard drive usage. NTFS or other file system?
Message-ID<lrduou$qmf$2@speranza.aioe.org>
Hello users.

I have an external hard drive and a question. Should I use NTFS on it, 
if I plan access only from GNU/Linux, or there is an advantage on using 
ext2 or ext4 file systems then?

[toc] | [next] | [standalone]


#11694

FromAragorn <thorongil@telenet.be.invalid>
Date2014-07-31 19:44 +0200
Message-ID<lrdv9a$ma1$1@dont-email.me>
In reply to#11693
On Thursday 31 July 2014 19:35, Evgenii Sputnik conveyed the following 
to comp.os.linux.misc...

> Hello users.
> 
> I have an external hard drive and a question. Should I use NTFS on it,
> if I plan access only from GNU/Linux, or there is an advantage on
> using ext2 or ext4 file systems then?

If you are planning to only use GNU/Linux for accessing that hard drive, 
then why would you create an inferior and non-native filesystem on it 
which doesn't even support UNIX/POSIX permissions and ownerships?

Go with ext4.

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

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


#11838

FromEvgenii Sputnik <esputnik7788@gmail.com>
Date2014-08-29 07:45 +0700
Message-ID<ltoifu$c5t$1@dont-email.me>
In reply to#11694
On 01/08/2014 00:44, Aragorn wrote:

> Go with ext4.

Why not ext2? I though it is for cases of such drives.

(Also thanks everyone else for the answers, really. I am still in 
thinking about replacing NTFS.)

-- 
Evgenii Sputnik

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


#11839

FromAragorn <thorongil@telenet.be.invalid>
Date2014-08-29 03:37 +0200
Message-ID<ltolgj$ubo$1@dont-email.me>
In reply to#11838
On Friday 29 August 2014 02:45, Evgenii Sputnik conveyed the following 
to comp.os.linux.misc...

> On 01/08/2014 00:44, Aragorn wrote:
> 
>> Go with ext4.
> 
> Why not ext2? I though it is for cases of such drives.
> 
> (Also thanks everyone else for the answers, really. I am still in
> thinking about replacing NTFS.)

Because ext2 is an index-sequential filesystem (which is slow), whereas 
ext4 is extent-based and used hashed trees (which is faster).

Please note that one does not have to use the journaling function.  It 
is perfectly possible to mount an ext4 (or other journaling) filesystem 
without the journaling enabled.  That is what happens when the 
filesystem is mounted read-only anyway.

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

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


#11840

FromRobert Heller <heller@deepsoft.com>
Date2014-08-28 21:09 -0500
Message-ID<aeydnXpdC-p0fWLOnZ2dnUU7-f2dnZ2d@giganews.com>
In reply to#11838
At Fri, 29 Aug 2014 07:45:50 +0700 Evgenii Sputnik <esputnik7788@gmail.com> wrote:

> 
> On 01/08/2014 00:44, Aragorn wrote:
> 
> > Go with ext4.
> 
> Why not ext2? I though it is for cases of such drives.

For rotating magnetic media drives, ext3 or ext4, depending on the level of
downward compatibility (if any) you need to support. For low-end SSD (eg thumb
drives), you don't want a journaling FS, either ext2 or ext4 w/out journaling.
And for thumb drives, the noatime mount option is probably a good idea -- the
less gratitious writes the better.

> 
> (Also thanks everyone else for the answers, really. I am still in 
> thinking about replacing NTFS.)

The *only* reason to use NTFS is compatibility with mess-windows.  If you have 
no plans for using the drive on a mess-windows box, you don't even want to 
consider NTFS, since it buys you nothing but possible trouble.  If you need to 
deal with a MacOSX machine, then hfsplus would be your choice.

> 

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
  

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


#11846

FromDavid Brown <david.brown@hesbynett.no>
Date2014-08-29 21:16 +0200
Message-ID<ltqjig$rs7$1@dont-email.me>
In reply to#11840
On 29/08/14 04:09, Robert Heller wrote:
> At Fri, 29 Aug 2014 07:45:50 +0700 Evgenii Sputnik <esputnik7788@gmail.com> wrote:
>
>>
>> On 01/08/2014 00:44, Aragorn wrote:
>>
>>> Go with ext4.
>>
>> Why not ext2? I though it is for cases of such drives.
>
> For rotating magnetic media drives, ext3 or ext4, depending on the level of
> downward compatibility (if any) you need to support. For low-end SSD (eg thumb
> drives), you don't want a journaling FS, either ext2 or ext4 w/out journaling.

Total nonsense.  The /tiny/ proportion of extra writes due to the 
journal is well worth the cost in wear.  And even the cheapest and 
smallest SSD will not wear out for decades of "normal" usage - it is far 
more likely for the controller electronics to fail, just like for hard 
disks.

USB sticks or "thumb drives" are not normally classified as SSD's, and 
have far simpler controllers.  People have occasionally managed to wear 
them out, but it's rare and requires a determined tester.  Given the 
risk of accidentally removing the drive before all writes have been 
committed, it is /definitely/ worth using a journalling filesystem on 
such drives.

> And for thumb drives, the noatime mount option is probably a good idea -- the
> less gratitious writes the better.

noatime is not a bad idea in general, since the writes are (for almost 
all uses) pointless, and thus have a very different balance than 
journals, which are very useful if something goes wrong.  Using noatime 
speeds up the drive, which is a good thing.

>
>>
>> (Also thanks everyone else for the answers, really. I am still in
>> thinking about replacing NTFS.)
>
> The *only* reason to use NTFS is compatibility with mess-windows.  If you have
> no plans for using the drive on a mess-windows box, you don't even want to
> consider NTFS, since it buys you nothing but possible trouble.  If you need to
> deal with a MacOSX machine, then hfsplus would be your choice.
>

Correct.

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


#11841

FromMladen Gogala <gogala.mladen@gmail.com>
Date2014-08-29 02:46 +0000
Message-ID<pan.2014.08.29.02.46.26@gmail.com>
In reply to#11694
On Thu, 31 Jul 2014 19:44:09 +0200, Aragorn wrote:


> If you are planning to only use GNU/Linux for accessing that hard drive,
> then why would you create an inferior and non-native filesystem on it
> which doesn't even support UNIX/POSIX permissions and ownerships?
> 
> Go with ext4.

Funny suggestion, having in mind that the latest Red Hat went with XFS. I 
had a bad experience with e4defrag and consider it inferior to the XFS. 
Here is the relevant part of my fstab:

/dev/mapper/fedora-root /                       ext4    defaults        1 
1
UUID=28c8bb15-8ea7-440a-9d7a-5cf7da3f7c76 /boot                   ext4    
defaults        1 2
/dev/mapper/fedora-home /home                   xfs     noatime,nobarrier 
0 0
/dev/mapper/fedora-swap swap                    swap    defaults        0 
0
/dev/sdb1 /misc                                 xfs	noatime,nobarrier  
0 0
/dev/sdb2 /data                                 xfs	noatime,nobarrier  
0 0
/dev/sdb3 /vbox                                 xfs	noatime,nobarrier  
0 0
[mgogala@medo ~]$ 

Wherever I could have avoided Ext4, I did.


-- 
Mladen Gogala
The Oracle Whisperer
http://mgogala.byethost5.com

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


#11842

FromAragorn <thorongil@telenet.be.invalid>
Date2014-08-29 05:14 +0200
Message-ID<ltor78$vgo$1@dont-email.me>
In reply to#11841
On Friday 29 August 2014 04:46, Mladen Gogala conveyed the following to 
comp.os.linux.misc...

> On Thu, 31 Jul 2014 19:44:09 +0200, Aragorn wrote:
> 
>> If you are planning to only use GNU/Linux for accessing that hard
>> drive, then why would you create an inferior and non-native
>> filesystem on it which doesn't even support UNIX/POSIX permissions
>> and ownerships?
>> 
>> Go with ext4.
> 
> Funny suggestion, having in mind that the latest Red Hat went with
> XFS.

A few remarks here...:

   1. XFS is brilliant.  I use and prefer it myself.  However, XFS
      is best when used with computers that are hooked up to a UPS,
      and on fixed-disk partitions - whether they be spinning rust
      or solid-state.  It's an aggressively caching filesystem.

   2. Most people aren't even aware that XFS exists, so I recommend
      what most people do know, which is ext4, given that it's an
      excellent filesystem.

   3. RedHat's recommendations are pretty worth nothing, really,
      because they also recommend systemd as an init replacement,
      PulseAudio, and GNOME with GDM as a desktop manager.

   4. Some distributions now default to btrfs, which is still rather
      experimental, and which is considered the new /Wunderkind/ of
      filesystems, offering the combination of filesystem and volume
      manager in one, similar to ZFS.

Given #3 and #4, I wouldn't pay too much attention to what a 
distribution chooses as the default for whatever.  Distributions - and 
especially RedHat - have their own agendas.

> I had a bad experience with e4defrag and consider it inferior to
> the XFS. [...]

There is no need to defrag a GNU/Linux-native filesystem, unless you've 
managed to fill it up almost completely.

As for whether ext4 is inferior to XFS, I don't know.  I personally 
prefer XFS - among other things because it's an industry standard - but 
I haven't had any bad experiences with ext4 yet either, and I wouldn't 
necessarily call ext4 "inferior".

Performance-wise, it all depends on what you want to do with it.  There 
are circumstances where XFS outperforms ext4, and other circumstances 
where the opposite is true.

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

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


#11844

FromWilliam Poaster <wp@dev.null>
Date2014-08-29 14:45 +0100
Message-ID<6pc6db-8gi.ln1@user-1943a.linux.individual.net>
In reply to#11842
It was reported that Aragorn posted:

> On Friday 29 August 2014 04:46, Mladen Gogala conveyed the following to 
> comp.os.linux.misc...
>
>> On Thu, 31 Jul 2014 19:44:09 +0200, Aragorn wrote:
>> 
>>> If you are planning to only use GNU/Linux for accessing that hard
>>> drive, then why would you create an inferior and non-native
>>> filesystem on it which doesn't even support UNIX/POSIX permissions
>>> and ownerships?
>>> 
>>> Go with ext4.
>> 
>> Funny suggestion, having in mind that the latest Red Hat went with
>> XFS.
>
> A few remarks here...:
>
>    1. XFS is brilliant.  I use and prefer it myself.  However, XFS
>       is best when used with computers that are hooked up to a UPS,
>       and on fixed-disk partitions - whether they be spinning rust
>       or solid-state.  It's an aggressively caching filesystem.
>
>    2. Most people aren't even aware that XFS exists, so I recommend
>       what most people do know, which is ext4, given that it's an
>       excellent filesystem.
>
>    3. RedHat's recommendations are pretty worth nothing, really,
>       because they also recommend systemd as an init replacement,
>       PulseAudio, and GNOME with GDM as a desktop manager.
>
>    4. Some distributions now default to btrfs, which is still rather
>       experimental, and which is considered the new /Wunderkind/ of
>       filesystems, offering the combination of filesystem and volume
>       manager in one, similar to ZFS.
>
> Given #3 and #4, I wouldn't pay too much attention to what a 
> distribution chooses as the default for whatever.  Distributions - and 
> especially RedHat - have their own agendas.
>
>> I had a bad experience with e4defrag and consider it inferior to
>> the XFS. [...]
>
> There is no need to defrag a GNU/Linux-native filesystem, unless you've 
> managed to fill it up almost completely.

Having used one version or another of GNU/Linux for 14+ years, I've never
had to defrag a drive. I've never even thought about it, except perhaps
when I was a n00b & first started using it.
Since its inception, I've always used ext4 without any problems. Before
that, I used Reiserfs & Reiser4 which I found a very good fs.

> As for whether ext4 is inferior to XFS, I don't know.  I personally 
> prefer XFS - among other things because it's an industry standard - but 
> I haven't had any bad experiences with ext4 yet either, and I wouldn't 
> necessarily call ext4 "inferior".
>
> Performance-wise, it all depends on what you want to do with it.  There 
> are circumstances where XFS outperforms ext4, and other circumstances 
> where the opposite is true.

I've never tried XFS, but I have tried btrfs. Although in its "infancy" I
find btrfs quite a reliable system.

-- 
Websites taking free content from usenet are parasites.
If you are not reading this in a USENET newsgroup, with a
newsreader application (Pan, Knode, Forte-Agent, etc) then 
you are probably using one of the parasitic websites.
USENET FAQ: http://www.reddit.com/r/usenet/wiki/faq

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


#11845

FromMladen Gogala <gogala.mladen@gmail.com>
Date2014-08-29 15:19 +0000
Message-ID<pan.2014.08.29.15.19.35@gmail.com>
In reply to#11844
On Fri, 29 Aug 2014 14:45:42 +0100, William Poaster wrote:

> Having used one version or another of GNU/Linux for 14+ years, I've
> never had to defrag a drive. I've never even thought about it, except
> perhaps when I was a n00b & first started using it.
> Since its inception, I've always used ext4 without any problems. Before
> that, I used Reiserfs & Reiser4 which I found a very good fs.

The reason for defragmenting a drive are virtual machines, of which I 
have quite a few. Since I am playing with thing like Oracle RAC, I 
frequently have to run 3 or 4 of them simultaneously. They perform 
visibly better if VMDK files are defragmented. The reason is simple to 
explain: a database full scan, which does a sequential scan on a virtual 
machine, will also do a sequential scan on the real drive if the 
underlying VMDK file is contiguous. If not, it will be translated into 
gazillion of small fragment scans, which can take time.
I don't really care about defragmenting /usr, /var or /opt. And with 3 or 
for VM's running, I don't have much memory for caching, even on my 16GB 
RAM desktop.
Regards,



-- 
Mladen Gogala
The Oracle Whisperer
http://mgogala.byethost5.com

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


#11848

FromPascal Hambourg <boite-a-spam@plouf.fr.eu.org>
Date2014-08-30 14:42 +0200
Message-ID<ltsgrt$1nge$1@saria.nerim.net>
In reply to#11845
Mladen Gogala a écrit :
> 
> The reason for defragmenting a drive are virtual machines, of which I 
> have quite a few. Since I am playing with thing like Oracle RAC, I 
> frequently have to run 3 or 4 of them simultaneously. They perform 
> visibly better if VMDK files are defragmented. The reason is simple to 
> explain: a database full scan, which does a sequential scan on a virtual 
> machine, will also do a sequential scan on the real drive if the 
> underlying VMDK file is contiguous. If not, it will be translated into 
> gazillion of small fragment scans, which can take time.

There is a huge gap between "contiguous" and "gazillion of small
fragments". If fragments are big enough (wrt. the disk sequential speed
* access time product), the adverse effects of fragmentation should be
minimized.

In ext4, isn't the use of extents supposed to reduce fragmentation and
improve large file performance ?

E.g. : Typical hard disk with 10 ms average access type and 100 MB/s
sequential speed. 100 MB/s * 10 ms = 1 MB. Extents in ext4 can map up to
128 MiB of contiguous space, which is two orders of magnitude bigger.

Besides, shouldn't VM managers be aware of this issue and grow virtual
disk files by big chunks in order to limit fragmentation too ?

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


#11849

FromRobert Heller <heller@deepsoft.com>
Date2014-08-30 09:09 -0500
Message-ID<u6OdnVdcnPaARpzJnZ2dnUU7-IudnZ2d@giganews.com>
In reply to#11848
At Sat, 30 Aug 2014 14:42:37 +0200 Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:

> 
> Mladen Gogala a écrit :
> > 
> > The reason for defragmenting a drive are virtual machines, of which I 
> > have quite a few. Since I am playing with thing like Oracle RAC, I 
> > frequently have to run 3 or 4 of them simultaneously. They perform 
> > visibly better if VMDK files are defragmented. The reason is simple to 
> > explain: a database full scan, which does a sequential scan on a virtual 
> > machine, will also do a sequential scan on the real drive if the 
> > underlying VMDK file is contiguous. If not, it will be translated into 
> > gazillion of small fragment scans, which can take time.
> 
> There is a huge gap between "contiguous" and "gazillion of small
> fragments". If fragments are big enough (wrt. the disk sequential speed
> * access time product), the adverse effects of fragmentation should be
> minimized.
> 
> In ext4, isn't the use of extents supposed to reduce fragmentation and
> improve large file performance ?
> 
> E.g. : Typical hard disk with 10 ms average access type and 100 MB/s
> sequential speed. 100 MB/s * 10 ms = 1 MB. Extents in ext4 can map up to
> 128 MiB of contiguous space, which is two orders of magnitude bigger.
> 
> Besides, shouldn't VM managers be aware of this issue and grow virtual
> disk files by big chunks in order to limit fragmentation too ?

I suspect that Mladen Gogala's problem is that a VMDK file is not really a
'disk' in the normal sense, but some kind of sparce copy-on-write psuedo disk
(which might be fine for 'toy' VMs on a desktop system with limited actual
disk space). If he was using 'real' disk space (eg a LVM logical volumn),
things might be different.

>                                                                                                             

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                                                        

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


#11851

FromPascal Hambourg <boite-a-spam@plouf.fr.eu.org>
Date2014-08-30 17:41 +0200
Message-ID<ltsrb7$1qv6$1@saria.nerim.net>
In reply to#11849
Robert Heller a écrit :
> At Sat, 30 Aug 2014 14:42:37 +0200 Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
> 
>> Mladen Gogala a écrit :
>>> The reason for defragmenting a drive are virtual machines, of which I 
>>> have quite a few. Since I am playing with thing like Oracle RAC, I 
>>> frequently have to run 3 or 4 of them simultaneously. They perform 
>>> visibly better if VMDK files are defragmented. [...]
>>
>> There is a huge gap between "contiguous" and "gazillion of small
>> fragments". If fragments are big enough (wrt. the disk sequential speed
>> * access time product), the adverse effects of fragmentation should be
>> minimized.
>>
>> In ext4, isn't the use of extents supposed to reduce fragmentation and
>> improve large file performance ?
[...]
>> Besides, shouldn't VM managers be aware of this issue and grow virtual
>> disk files by big chunks in order to limit fragmentation too ?
> 
> I suspect that Mladen Gogala's problem is that a VMDK file is not really a
> 'disk' in the normal sense, but some kind of sparce copy-on-write psuedo disk
> (which might be fine for 'toy' VMs on a desktop system with limited actual
> disk space). If he was using 'real' disk space (eg a LVM logical volumn),
> things might be different.

A VMDK _file_ is of course not a raw block device but a file in a
filesystem. The default granularity for sparse VMDK files seems to be 64
KiB, which is way too small to avoid fragmentation issues by itself.
However shouldn't it benefit from ext4 extents ?

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


#11852

FromKeith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Date2014-08-30 15:21 -0700
Message-ID<icv9dbxot.ln2@goaway.wombat.san-francisco.ca.us>
In reply to#11851
On 2014-08-30, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
> Robert Heller a écrit :
>> 
>> I suspect that Mladen Gogala's problem is that a VMDK file is not really a
>> 'disk' in the normal sense, but some kind of sparce copy-on-write psuedo disk
>> (which might be fine for 'toy' VMs on a desktop system with limited actual
>> disk space). If he was using 'real' disk space (eg a LVM logical volumn),
>> things might be different.
>
> A VMDK _file_ is of course not a raw block device but a file in a
> filesystem. The default granularity for sparse VMDK files seems to be 64
> KiB, which is way too small to avoid fragmentation issues by itself.
> However shouldn't it benefit from ext4 extents ?

IIRC there are two different types of virtual disks made by VirtualBox
(and possibly VMWare).  One is where disk space is allocated as you
suggest, but it is possible to assign all disk space immediately on
creating the virtual disk.  I think that would be sufficient to avoid
fragmentation issues on the host OS, and then it would be up to the
guest to avoid fragmentation issues within its filesystems (which as
people have pointed out most linux filesystems already do).

--keith


-- 
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

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


#11854

FromMladen Gogala <gogala.mladen@gmail.com>
Date2014-08-31 17:13 +0000
Message-ID<pan.2014.08.31.17.13.55@gmail.com>
In reply to#11849
On Sat, 30 Aug 2014 09:09:33 -0500, Robert Heller wrote:

> I suspect that Mladen Gogala's problem is that a VMDK file is not really
> a 'disk' in the normal sense, but some kind of sparce copy-on-write
> psuedo disk (which might be fine for 'toy' VMs on a desktop system with
> limited actual disk space). If he was using 'real' disk space (eg a LVM
> logical volumn), things might be different.

Of course VMDK file is not really a disk and virtual machine is not 
really a machine. With VMWare, it is possible to use LVM logical volume 
instead of file, it's called "RDM", which stands for "raw disk mapping". 
Essentially, it's a real LUN is mapped to the virtual machine to use it. 
However, I am using a desktop class machine and unfortunately don't have 
an EMC VMAX in my living room. It is very unlikely that I will ever have 
a full fledged SAN, so I am stuck with the files. VirtualBox cannot do 
RDM, but it doesn't really matter. 
As for the thin provisioning (a growing disk), I avoid it like a plague 
because it slows things down. My RDBMS/VM server is not a really fast 
machine and I am trying to get a decent performance out of it. That is 
why I defragment my file systems and use XFS.



-- 
Mladen Gogala
The Oracle Whisperer
http://mgogala.byethost5.com

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


#11855

FromRobert Heller <heller@deepsoft.com>
Date2014-08-31 13:24 -0500
Message-ID<EKWdnbvNV4_M9Z7JnZ2dnUU7-YednZ2d@giganews.com>
In reply to#11854
At Sun, 31 Aug 2014 17:13:55 +0000 (UTC) Mladen Gogala <gogala.mladen@gmail.com> wrote:

> 
> On Sat, 30 Aug 2014 09:09:33 -0500, Robert Heller wrote:
> 
> > I suspect that Mladen Gogala's problem is that a VMDK file is not really
> > a 'disk' in the normal sense, but some kind of sparce copy-on-write
> > psuedo disk (which might be fine for 'toy' VMs on a desktop system with
> > limited actual disk space). If he was using 'real' disk space (eg a LVM
> > logical volumn), things might be different.
> 
> Of course VMDK file is not really a disk and virtual machine is not 
> really a machine. With VMWare, it is possible to use LVM logical volume 
> instead of file, it's called "RDM", which stands for "raw disk mapping". 
> Essentially, it's a real LUN is mapped to the virtual machine to use it. 
> However, I am using a desktop class machine and unfortunately don't have 
> an EMC VMAX in my living room. It is very unlikely that I will ever have 
> a full fledged SAN, so I am stuck with the files. VirtualBox cannot do 
> RDM, but it doesn't really matter. 

*I* use a 'desktop class machine' and use LVM and XEN under CentOS 5. I have 
8gig of RAM and 250Gig of hard drive space.  (No I don't have a SAN either, 
but I do run software RAID on my 'desktop class machine'.  I would just as 
soon NOT use something really lame like VirtualBox.  I'd run XEN (or with a 
newer O/S, KVM).  


> As for the thin provisioning (a growing disk), I avoid it like a plague 
> because it slows things down. My RDBMS/VM server is not a really fast 
> machine and I am trying to get a decent performance out of it. That is 
> why I defragment my file systems and use XFS.
> 
> 
> 

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                  

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


#11857 — Is VirtualBox "lame"? (Was: something else...)

Fromgazelle@shell.xmission.com (Kenny McCormack)
Date2014-08-31 20:23 +0000
SubjectIs VirtualBox "lame"? (Was: something else...)
Message-ID<lu007f$trj$1@news.xmission.com>
In reply to#11855
In article <EKWdnbvNV4_M9Z7JnZ2dnUU7-YednZ2d@giganews.com>,
Robert Heller  <heller@deepsoft.com> wrote:
...
>I would just as 
>soon NOT use something really lame like VirtualBox.

What makes you say that VB is lame?

-- 
(The Republican mind, in a nutshell)
You believe things that are incomprehensible, inconsistent, impossible
because we have commanded you to believe them; go then and do what is
unjust because we command it. Such people show admirable reasoning. Truly,
whoever is able to make you absurd is able to make you unjust. If the
God-given understanding of your mind does not resist a demand to believe
what is impossible, then you will not resist a demand to do wrong to that
God-given sense of justice in your heart. As soon as one faculty of your
soul has been dominated, other faculties will follow as well. And from this
derives all those crimes of religion which have overrun the world.

(Alternative condensed translation)
"Those who can make you believe absurdities, can make you commit atrocities".

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


#11858 — Re: Is VirtualBox "lame"? (Was: something else...)

FromRobert Heller <heller@deepsoft.com>
Date2014-08-31 15:51 -0500
SubjectRe: Is VirtualBox "lame"? (Was: something else...)
Message-ID<w7SdnR8PFZFOF57JnZ2dnUU7-LWdnZ2d@giganews.com>
In reply to#11857
At Sun, 31 Aug 2014 20:23:11 +0000 (UTC) gazelle@shell.xmission.com (Kenny McCormack) wrote:

> 
> In article <EKWdnbvNV4_M9Z7JnZ2dnUU7-YednZ2d@giganews.com>,
> Robert Heller  <heller@deepsoft.com> wrote:
> ...
> >I would just as 
> >soon NOT use something really lame like VirtualBox.
> 
> What makes you say that VB is lame?

I found it had several 'funcky' aspects: *I* found its GUI had some 'mis
features'. It did not give the level of control/access to the VMs that, for
example, virsh does (or even virt-manager). It gave me the impression that it
was something of a 'toy' system: fine for light duty use for people who need a
VM for somewhat occassional use. If you want to do more serious work, you
would be better served by either xen or kvm. There was a poster on the
original thread that was having trouble with fragmentation working with a DB
system (Oracle I think) that was using VB. People suggested that he move to
kvm, but he claimed that he just had a desktop system, and I said I was using
xen & lvm volumns on a fairly modest (by current standards) desktop system, so
there really was no reason to be stuck with VB. 

> 

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                                          

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


#11861 — Re: Is VirtualBox "lame"?

FromRich <rich@example.invalid>
Date2014-08-31 23:58 +0000
SubjectRe: Is VirtualBox "lame"?
Message-ID<lu0cr1$92c$1@dont-email.me>
In reply to#11858
Robert Heller <heller@deepsoft.com> wrote:
> At Sun, 31 Aug 2014 20:23:11 +0000 (UTC) gazelle@shell.xmission.com (Kenny McCormack) wrote:

> > 
> > In article <EKWdnbvNV4_M9Z7JnZ2dnUU7-YednZ2d@giganews.com>,
> > Robert Heller  <heller@deepsoft.com> wrote:
> > ...
> > >I would just as 
> > >soon NOT use something really lame like VirtualBox.
> > 
> > What makes you say that VB is lame?

> I found it had several 'funcky' aspects: *I* found its GUI had some 'mis
> features'. It did not give the level of control/access to the VMs that, for
> example, virsh does (or even virt-manager).

The gui for VirtualBox is limited in what it will allow you to
accomplish.

For the truly advanced stuff, you have to use VBoxManage from the
command line.

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


#11863 — Re: Is VirtualBox "lame"?

FromRobert Heller <heller@deepsoft.com>
Date2014-08-31 21:54 -0500
SubjectRe: Is VirtualBox "lame"?
Message-ID<N_KdnWM2g4VSQp7JnZ2dnUU7-IWdnZ2d@giganews.com>
In reply to#11861
At Sun, 31 Aug 2014 23:58:25 +0000 (UTC) Rich <rich@example.invalid> wrote:

> 
> Robert Heller <heller@deepsoft.com> wrote:
> > At Sun, 31 Aug 2014 20:23:11 +0000 (UTC) gazelle@shell.xmission.com (Kenny McCormack) wrote:
> 
> > > 
> > > In article <EKWdnbvNV4_M9Z7JnZ2dnUU7-YednZ2d@giganews.com>,
> > > Robert Heller  <heller@deepsoft.com> wrote:
> > > ...
> > > >I would just as 
> > > >soon NOT use something really lame like VirtualBox.
> > > 
> > > What makes you say that VB is lame?
> 
> > I found it had several 'funcky' aspects: *I* found its GUI had some 'mis
> > features'. It did not give the level of control/access to the VMs that, for
> > example, virsh does (or even virt-manager).
> 
> The gui for VirtualBox is limited in what it will allow you to
> accomplish.
> 
> For the truly advanced stuff, you have to use VBoxManage from the
> command line.

Which I also found lacking in many ways. I had been using virsh & crew with
xen on my CentOS 5 box and when I had to deal with VirtualBox on a Debian 7
system (somewhat forced because tails and whonix were hardwired to use
VirtualBox), I was greatly disappointed. virsh and virt-manager with xen or kvm
are just more functional overall and things are so much more 'integrated' with
the core (Linux) operating system. One really bad feature was things like file
ownership with VirtualBox was that the virtual machine configurations were
owned by the unpriv user I was running VirtualBox with and were not really
sharable.  This had too much of a 'toy-ness' feel to it.  *I* would never use 
VirtualBox if I needed to run a VM as a server or something like that (I have 
a Ubuntu 14.04 VM running as a server on a CentOS 6 physical server using 
KVM). 

> 
>                                                 

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                        

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


Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.linux.misc


csiph-web